哪些 MySQL 存储引擎真正支持外键？
只有
InnoDB在生产环境中稳定、完整地支持外键约束。其他常见引擎如
MyISAM、
MEMORY、
CSV、
ARCHIVE均不支持——哪怕你写上
FOREIGN KEY语法，MySQL 也不会报错（尤其在非严格模式下），但该约束完全不生效，形同虚设。
虽然
NDB（MySQL Cluster）也支持外键，但它有额外配置要求和显著的性能开销，日常单机部署几乎不用。所以结论很直接：要用外键，必须用
InnoDB，且两张表都得是
InnoDB。
为什么建外键总失败？常见硬性条件清单
即使用了
InnoDB，外键创建仍可能静默失败或报错，原因往往卡在几个刚性条件上：
FOREIGN KEY列和被引用列（如
users.id）的数据类型必须严格一致：包括类型（
INTvs
BIGINT）、符号（
SIGNEDvs
UNSIGNED）、长度（
INT(10)和
INT(11)在某些版本中会拒绝） 被引用列必须有索引——主键自动满足，但若引用的是非主键唯一列（如
UNIQUE INDEX父表必须先于子表存在；不能一边建表一边跨表引用未定义的表 字符集与排序规则（
COLLATION）最好一致，尤其是
VARCHAR类型，否则可能触发隐式转换失败
外键不是“自动索引”，但依赖索引实时检查
很多人误以为加了外键就等于优化了关联查询，其实不然：
InnoDB的外键约束本身不创建索引，但它强制要求外键列必须有索引（否则建表失败）。这个索引的作用是加速约束检查——比如插入一条
orders记录时，
InnoDB要快速确认
user_id是否真存在于
users表中。
如果你没手动建索引，MySQL 5.7+ 会在加外键时自动补一个，但这个索引只服务约束检查，未必适配你的查询场景。所以建议：为外键列单独建索引，并按常用查询条件组合扩展，例如
INDEX (user_id, status)。
级联操作（CASCADE）看着方便，但藏着性能雷
ON DELETE CASCADE或
ON UPDATE CASCADE是外键最诱人的特性，但它们不是“原子事务内完成”的轻量操作。实际执行时，
InnoDB会主动发起对子表的 DML 操作——这意味着一次父表删除，可能触发成百上千次子表扫描+更新/删除，锁住大量行甚至导致超时。
更隐蔽的问题是：这些级联动作不会记录在 binlog 的原始语句中，而是以独立事件形式写入，给逻辑备份、审计、数据迁移带来干扰。生产环境若真要用
CASCADE，务必先压测子表数据量级，且避免在高频更新的父表主键上启用
ON UPDATE CASCADE。
最容易被忽略的一点：外键检查发生在语句执行期，而非事务提交时。也就是说，即使你把多条 INSERT 包在一个事务里，每条语句执行时都会立即校验外键，失败则立刻中断——它不像某些 ORM 的延迟验证，没有“攒一批再统一校验”的余地。
