本文探讨了物理外键在数据库中可能导致的性能问题，如额外的资源消耗、潜在的死锁风险以及对扩展性的限制。同时，提到了外键设计在某些数据库系统中的不足。建议在考虑数据库扩展性和灵活性时，可以采用逻辑外键，通过程序逻辑来保证关联关系。文中还提出了数据库策略，如逻辑删除和事务处理，以应对物理外键的限制。
物理外键性能问题
物理外键性能问题总结：
1.数据库需要维护外键的内部管理
2.外键等于把数据的一致性实物实现，全部交给数据库的服务器完成
3.有了外键，当做一些设计外键字段的增、删、更新操作之后，需要触发相关操作去检查，
不得不消耗资源
4.外键还会印象需要请求对其他表内部加锁而容易出现死锁的情况
mysql的外键设计问题 虽然很多人都不推荐你在关系型数据库使用外键
但你更多听到的是mysql的，而不是SQLserver或者其他。比较公认的是，他的外键设计的 的确不是很好，
限制多功能不强大等，以innodb为例子，包含但不限于以下几点(我以为比较严重的)所有tables必须是
InnoDB 型，它们不能是临时表。在引用表中，必须有一个索引，外键列以同样的顺序被列在期中作为第一列。
这样一个索引如果不存在，它必须在引用表里被自动创建。不支持对外建列的索引前缀。这样的后果之一是
BLOB和TEXT列不被包括在一个外键中，这是因为对这些列的索引必须总是包含一个前缀长度 InnoDB不对
那些外键活包含NULL列的被引用键值检查外键约束
外键对扩展性的限制和影响外键的主从关系
如果你每天数据库关联都是使用物理外键，但是如果哪天主键所在的表需要拆分或重构。
如果哪天你发现外键表不是非要跟主表的主键挂上关系 ，这种情况并不少见，尤其是数据库
设计者水平不够高的时候。
另一个方面，数据库帮你保证级联关系，平时写程序的时候思路足够清晰吗，因为某些原因
(比如你需要的关系数据库并不支持，mysql经常发生)，有些地方你就不能去设置物理外键了，
当有级联更新的需求时，一部分靠物理外键，一部分靠自己，其实还不如全使用代码逻辑去保证
如果你需要分库分表的时候，物理外键就没什么用了。
逻辑外键在业界内是比较成熟的外键，即使不使用物理外键，我们也能约定逻辑外键（不在
数据库声明外键，在程序实现上表达关联关系）
数据库上的策略：
可以选择大多数情况下我们只更新不删除，也就是逻辑删除，
不再使用的历史数据定期归档来减少压力
代码的设计和限制：
对表范围的操作限制，开启事务去处理逻辑，
有需要异步操作来提高性能的，我们设计补偿机制去弥补
扫一扫
1599
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
