myisam完全忽略外键语法，不校验、不报错、不保留定义；innodb依托事务、行锁、聚簇索引和二级索引实现安全级联操作，修改级联规则需先删后建外键。
MyISAM根本不校验外键，连报错都不做
MyISAM引擎在解析 FOREIGN KEY 语法时直接忽略，既不建约束，也不提示错误。你执行 CREATE TABLE ... FOREIGN KEY 看似成功，实际查 SHOW CREATE TABLE 就会发现外键定义完全消失。这不是“不支持”，而是“假装没看见”。所以一旦误用 MyISAM，数据一致性全靠应用层硬扛，出问题很难回溯。
InnoDB 的事务和行锁机制是级联操作的基础
级联删除不是简单地多发几条 DELETE，它必须和父表操作在同一个事务里原子执行。InnoDB 的 MVCC、行级锁、崩溃恢复能力，让 ON DELETE CASCADE 能安全地：
- 在删除父记录前，先加锁子表相关行
- 检查子表是否可写（比如有没有触发器阻塞）
- 把所有级联动作记入 undo log，保证回滚一致
- 把整套操作写进 binlog（MySQL 9.6.0 起已统一 SQL 层处理，彻底解决 CDC 主从不一致）
而 MyISAM 是表锁 + 无事务，根本无法支撑这种跨表原子性。
索引结构差异决定外键能否高效验证
InnoDB 的聚簇索引天然把主键和数据组织在一起，外键列只要建了二级索引（INDEX (sid)），就能用 B+ 树快速反查是否存在引用。MyISAM 的索引和数据分离，且不支持外键所需的“存在性快速判定 + 锁定”组合能力。这也是为什么建外键前必须手动加索引——InnoDB 需要它来加速约束检查，不是可选项。
ALTER TABLE 加级联规则时容易踩的坑
已经建好外键但没设 ON DELETE CASCADE？别指望 ALTER TABLE ... ADD CONSTRAINT 覆盖旧约束。InnoDB 不允许直接修改已有外键的动作类型。你得：
- 先用 SHOW CREATE TABLE 查出当前外键名（比如 fk_sc_sid）
- 执行 ALTER TABLE sc DROP FOREIGN KEY fk_sc_sid
- 再用完整 ADD CONSTRAINT ... FOREIGN KEY ... ON DELETE CASCADE 重建
过程中表会被锁，大表务必避开高峰。
外键不是开关，是数据库内核能力的映射；用错引擎，等于把安全带剪断再上高速。
