老马失前蹄，竟然在数据库外键上翻车了，重温外键级联
祸起 dev environment某天晚上，群里突然有人@我，说开发环境出现报错，一查发现是我负责的接口出了问题，瞬间虎躯一震，赶紧定位问题。
https://img2024.cnblogs.com/blog/1084317/202603/1084317-20260322103220326-384878368.png
谜底就在谜面上：主表数据被删除，但子表仍保留外键约束，导致删除操作直接失败。
三分钟解决问题，行云流水，毫不拖泥带水。
反思与复盘
但这件事引发了我的反思：这种错误太低级了，低级到刚毕业的我都不可能犯，但工作多年后的我反而踩坑了。
复盘原因，主要有三点：
[*]对外键本质理解不够深入
人云亦云、浅尝辄止，没有真正吃透原理。
温故而知新，希望未来不再被同样的问题“回旋镖”命中。
[*]过度依赖 DBA 兜底，思考偷懒
经验主义害人，任何技术点都不能“不带脑子”。
[*]对业务上游逻辑不够熟悉
不知道上游业务会执行删除操作。
后续需要加强业务文档沉淀、多总结、多梳理。
外键 Foreign Key 解析
什么是外键？
数据库外键，是一个熟悉又陌生的词。
[*]熟悉：大学就学过，工作天天提
[*]陌生：商业项目里几乎从不真正启用
<blockquote>
至于为什么不建外键？别问，问就是互联网公司传统！
当然，主要是没权限。
那为什么现在又开始建了？
一代版本一代神，换工作了
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]