外键约束本身不保证事务一致性
外键约束（
FOREIGN KEY）只负责在单条语句执行时校验引用完整性，比如
INSERT或
UPDATE时检查被引用的
id是否存在。它不参与事务的原子性控制——即使你在一个事务里先删父记录、再删子记录，外键会立刻报错
Cannot delete or update a parent row: a foreign key constraint fails，但这不是事务在“保证一致性”，而是约束在“阻止不一致操作”。
真正靠事务来兜底的是
ROLLBACK机制：只要你在事务中执行多步操作，其中任意一步因外键失败或其它原因中断，整个事务可回滚。
ON DELETE / ON UPDATE 的行为必须显式声明
MySQL 默认不会自动级联删除或更新，哪怕加了外键，也要明确写
ON DELETE CASCADE或
ON DELETE SET NULL等子句，否则默认是
RESTRICT（即拒绝操作）。
ON DELETE CASCADE：删父表行时自动删所有子表关联行 —— 快但危险，容易误删
ON DELETE SET NULL：要求对应列为
NULLABLE，否则建表失败
ON DELETE RESTRICT：隐式默认值，不写也会生效，但建议显式写出，避免误解 注意：
SET DEFAULT在 InnoDB 中不支持，会静默转为
RESTRICT
事务隔离级别对外键检查无影响
外键约束检查发生在语句执行阶段（statement-level），而不是事务提交时。无论你用
READ COMMITTED还是
REPEATABLE READ，只要语句执行时被引用行不可见（比如被另一个未提交事务锁住或已删除），就会立即报错，不会等到
COMMIT才检查。
这意味着：
外键检查不依赖 MVCC 版本可见性规则 如果子表插入依赖一个尚未提交的父表插入，会直接报Cannot add or update a child row想绕过这个限制，只能提前提交父表事务，或改用应用层校验 + 延迟约束（MySQL 不支持延迟约束，PostgreSQL 才支持）
外键与性能、锁行为密切相关
加了外键后，MySQL（InnoDB）会在相关操作中自动加锁，范围比你直觉中更大：
插入子表时，会对父表被引用的那行加shared lock（S 锁），防止父行被删/改 删除父表行时，会先对子表扫描匹配行（即使有索引），并加
next-key lock，可能阻塞并发插入 没给子表外键列建索引？会触发全表扫描 + 表级锁，高并发下极易卡死 建议：所有外键列必须单独建索引（
INDEX），否则 DML 性能断崖下跌
ALTER TABLE orders ADD INDEX idx_customer_id (customer_id);外键不是银弹。它把一部分数据逻辑推给了存储引擎，省了应用层判断，但也带来了锁行为不可控、迁移困难、分库分表难适配等问题。真要强一致性，得靠事务 + 应用层重试 + 补偿逻辑，而不是指望外键自己扛住所有边界。
