外键约束为什么没生效
MySQL 中外键只在
InnoDB引擎下有效，
MyISAM表即使写了
FOREIGN KEY语法也不会真正约束。建表时务必确认存储引擎：
CREATE TABLE orders ( id INT PRIMARY KEY, user_id INT, FOREIGN KEY (user_id) REFERENCES users(id) ) ENGINE=InnoDB;如果用的是
ALTER TABLE添加外键，需确保字段类型完全一致（比如都是
INT UNSIGNED），否则报错
ERROR 1005 (HY000): Can't create table。
CASCADE、SET NULL 和 RESTRICT 的实际行为差异
级联动作定义在
ON DELETE或
ON UPDATE子句中，不同选项直接影响数据一致性：
CASCADE：父记录删掉，子记录自动删；父键更新，子外键同步更新。适合强依赖关系，比如订单项随订单删除
SET NULL：父记录删除后，子表对应外键字段设为
NULL—— 但该字段必须允许
NULL，否则建表失败
RESTRICT（默认）：父记录有子记录时，禁止删除或更新，直接报错
ERROR 1451 (23000): Cannot delete or update a parent row
示例：
ALTER TABLE orders ADD CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE ON UPDATE CASCADE;
外键名重复或缺失导致的常见操作失败
MySQL 要求每个外键名在数据库内唯一。若执行两次相同
ALTER TABLE ... ADD FOREIGN KEY，会因外键名冲突报错
ERROR 1022 (23000): Can't write; duplicate key in table。建议显式命名外键： 建表时用
CONSTRAINT fk_orders_user_id明确命名 删外键必须用名字：
ALTER TABLE orders DROP FOREIGN KEY fk_orders_user_id;不指定名字时，MySQL 自动生成类似
orders_ibfk_1的名称，可通过
SHOW CREATE TABLE orders;查看
线上环境慎用 CASCADE 的真实风险
看似省事的
ON DELETE CASCADE在大表上可能引发连锁锁表和慢查询。比如删一个用户，触发删除数万条订单及关联的订单明细，整个事务持锁时间长，阻塞其他写操作。更稳妥的做法是： 业务层分步处理：先查出子记录 ID 列表，再分批删除，控制事务粒度 用
RESTRICT+ 应用层兜底校验，避免误删 若必须用级联，确保子表有合适的索引 —— 外键列本身会自动建索引，但复合查询条件仍可能走全表扫描
外键不是银弹，尤其在高并发写入场景下，它的约束开销和级联副作用比看起来更重。
