MyISAM表转InnoDB后外键加不上，根本原因是引擎切换仅是前提，还需满足四条件：被引用列须为主键或唯一索引、字段类型及字符集完全一致、子表数据全部存在于主表、外键约束必须显式命名；否则报ERROR 1005或1215。
MyISAM表转InnoDB后外键根本加不上？先确认引擎和索引
直接执行 ALTER TABLE ADD FOREIGN KEY 报错 ERROR 1005 或 ERROR 1215，大概率不是语法问题，而是底层条件不满足。MyISAM 表转换后，ENGINE=InnoDB 只是第一步，但外键依赖的索引、字段类型、字符集等全部归零重来。
- 用
SHOW CREATE TABLE table_name确认引擎已为InnoDB，且没有残留ENGINE=MyISAM - 被引用列（如
users.id）必须是PRIMARY KEY或带UNIQUE约束的列；仅普通INDEX不行 - 子表外键列（如
orders.user_id）与父表被引用列必须完全同型：类型、长度、符号（SIGNED/UNSIGNED）、字符集、排序规则（COLLATION）四者缺一不可 - 已有数据必须能匹配——如果
orders.user_id里存了users表中不存在的 ID，ADD FOREIGN KEY会直接失败，报Cannot add or update a child row
ALTER TABLE ADD FOREIGN KEY 必须显式命名约束
MyISAM 转过来的表，加外键不能只写 FOREIGN KEY (col) REFERENCES ...，MySQL 会静默忽略或报语法错误。InnoDB 要求约束名必须存在，否则无法后续管理（比如删外键）。
- 正确写法：
ALTER TABLE orders ADD CONSTRAINT fk_orders_user_id FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE RESTRICT; - 约束名（如
fk_orders_user_id）建议按fk_子表_外键列命名，避免重复和歧义 - 删外键时必须用这个名：
ALTER TABLE orders DROP FOREIGN KEY fk_orders_user_id;—— 注意这里不加括号，也不是删列 - 不命名就加，MySQL 可能自动生成一个难读的名字（如
orders_ibfk_1），线上环境排查困难
ON DELETE / ON UPDATE 行为选错等于埋雷
不写 ON DELETE 就默认 RESTRICT，不是“不管”，而是“一删就报错”。很多人误以为这样安全，结果业务里批量删用户时整个事务卡死。
-
ON DELETE CASCADE：适合强生命周期绑定，如user → user_settings，但订单表配它极危险——误删用户会连带清空所有历史订单 -
ON DELETE SET NULL：要求外键列允许NULL（即定义时没加NOT NULL），适合解耦场景，如部门删除后员工记录保留但dept_id置空 -
ON UPDATE CASCADE几乎不该用：主键本就不该更新；若真要改，说明设计有缺陷（比如拿手机号当主键） - 生产环境优先选
RESTRICT或SET NULL，并确保应用层逻辑兜底——外键拦不住多步操作中间崩溃
外键生效后别忘了补索引和关掉 FOREIGN_KEY_CHECKS
外键列本身不自动建索引，但没索引会导致关联查询慢、DELETE/UPDATE 父表时锁表范围极大，甚至拖垮整个库。
- 手动加索引：
CREATE INDEX idx_orders_user_id ON orders(user_id);（即使已有外键也得加） - 开发调试时可能临时关过
FOREIGN_KEY_CHECKS=0，但这个设置不持久、不跨连接；长连接复用后若忘记开，脏数据就进来了，且无任何提示 - 检查当前状态：
SELECT @@FOREIGN_KEY_CHECKS;—— 上线前务必确认是1 - 大表加外键+索引过程会锁表，建议在低峰期操作，并提前在从库验证
SHOW ENGINE INNODB STATUS是否有锁冲突
