MyISAM不支持外键约束，仅InnoDB支持；MyISAM遇到FOREIGN KEY语法会静默忽略，不报错也不校验，导致引用完整性完全失效，必须依赖应用层手动保障一致性。
MyISAM表加了FOREIGN KEY语法却没报错，但约束不生效
这是最典型的“假支持”现象。MyISAM引擎遇到FOREIGN KEY定义时，既不报错也不执行校验逻辑——它直接忽略该子句，只按需创建一个普通索引（如果还没建的话）。结果就是：SHOW CREATE TABLE里看不到FOREIGN KEY关键字，INFORMATION_SCHEMA.KEY_COLUMN_USAGE查不到记录，插入user_id = 999999这种明显不存在的值也完全畅通无阻。
外键缺失导致应用层必须承担全部一致性责任
没有引擎层的强制拦截，所有引用完整性检查都得靠代码写死：
- 每次
INSERT INTO orders前，必须显式SELECT COUNT(*) FROM users WHERE id = ?，且要处理并发写入带来的竞态（比如查完存在，下一秒就被删了） -
DELETE FROM users前，得先SELECT COUNT(*) FROM orders WHERE user_id = ?，再决定是拒绝、级联删还是置空——而这些逻辑分散在各处，极易遗漏或不一致 - 数据修复成本陡增：一旦出现孤儿记录（如
orders.user_id指向不存在的users.id），只能靠定时脚本扫描+人工核对，无法自动阻断源头
InnoDB外键已启用，但MyISAM残留表仍在破坏整体一致性
混合引擎环境比纯MyISAM更危险。常见场景包括：
- 历史表未迁移：老系统中
log_table ENGINE=MyISAM和新业务表orders ENGINE=InnoDB共存，外键只管得着InnoDB表，对MyISAM表的误操作毫无反应 - 临时表陷阱：应用用
CREATE TEMPORARY TABLE tmp ENGINE=MyISAM做中间计算，后续又拿它去JOIN主业务表，结果把非法关联带进最终结果 - 备份还原后失效：mysqldump导出时若未指定
--set-gtid-purged=OFF或引擎参数，恢复后可能默认建为MyISAM，外键瞬间归零
真正影响一致性的不是“有没有外键”，而是“有没有统一的约束执行点”
MyISAM的设计哲学是牺牲完整性换读性能，这本身没问题；问题在于团队误以为“语法能写通=功能可用”。哪怕只有一张MyISAM表参与关键业务流程，整个链路的一致性保障就出现了不可绕过的缺口——因为约束执行点从数据库层退回到了每段应用代码里，而人写的逻辑永远比机器执行的规则更容易出错、更难审计。
