数据库物理外键、逻辑外键

为什么现在很多公司都禁止使用物理外键？

物理外键：某张表的字段使用foreignkey作为外键关联另外一张表、字段。并且限定引擎为inno DB；

逻辑外键：又叫事物外键，不使用foreignkey，使用语法（代码）上产生逻辑关联而产生的外键；

两张表使用物理外键进行关联：

1 已有一张表为Persons表，表结构为
P_Id LastName  FirstName Address City；
2 创建一个带有外键的Order表
CREATE TABLE Orders
(
O_Id int NOT NULL,
OrderNo int NOT NULL,
P_Id int,
PRIMARY KEY (O_Id),
FOREIGN KEY (P_Id) REFERENCES Persons(P_Id)
)

此时使用navicat查看时，会更明显看到有个foreignkey的标识，
查询起来可以更方便的联表查询，通过外键可以直接调用另一张表的查询。

两张表使用逻辑外键进行关联：

1 已有一张表为Persons表，表结构为
P_Id LastName  FirstName Address City；
2 创建一个带有外键的Order表
CREATE TABLE Orders
(
O_Id int NOT NULL,
OrderNo int NOT NULL,
P_Id int
)

此时使用navicat查看时，不会看到foreignkey的标识，此时两张表从数据库的角度看是毫无关联的。
其中Orders表的P_Id 与 Persions表的 P_Id 是有关联关系，增删改查上都是有关系的，而这种关系是通过代码逻辑层面进行控制。所以叫逻辑外键。

从维护上来看，逻辑外键由于需要使用代码来进行维护，好像更麻烦；物理外键无需代码维护直接使用mysql自身维护，好像更简单。

实际上物理外键是有性能问题的：

1. 数据库需要维护外键的内部管理；
2. 外键等于把数据的一致性事务实现，全部交给数据库服务器完成；
3. 有了外键，当做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，而不得不消耗资源；
4. 外键还会因为需要请求对其他表内部加锁而容易出现死锁情况
5. 所有tables必须是InnoDB型，它们不能是临时表
6. 不支持对外键列的索引前缀。这样的后果之一是BLOB和TEXT列不被包括在一个外键中，这是因为对这些列的索引必须总是包含一个前缀长度
7. InnoDB不对那些外键或包含NULL列的被引用键值检查外键约束

如果数据量上去后，使用物理外键会大大的降低性能，特别是出现死锁情况。

其中优化数据库中的一个方向是避免大事务，尽量将大事务拆成多个小事务来处理，小事务发生锁冲突的几率也更小。

当采用物理外键时，此时一个事物同时最少是需要更新2张表。此时是需要同时最少锁住两张的表的。如果拆分后，则两张锁住的时间是不同步的。造成死锁的概率更小。