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