外键和触发器均会显著降低mysql写入性能。外键需校验引用完整性并加锁，若父表索引缺失易致全表扫描；触发器逻辑隐藏、无法替代外键约束，且高并发下二者均延长锁持有时间、增加死锁风险。
外键约束在写入时会明显拖慢性能
MySQL 的外键（FOREIGN KEY）不是“免费”的。每次 INSERT、UPDATE 或 DELETE 涉及外键列，InnoDB 都要加锁并校验引用完整性——尤其是被引用表（父表）的索引必须存在且高效，否则会触发全表扫描式检查。
常见错误现象：Lock wait timeout exceeded、大批量导入卡死、主从延迟飙升。典型场景是订单表带 user_id 外键，而用户表没对 id 建主键（或用了非聚簇索引），此时每插一条订单都要扫一遍用户表。
- 务必确保被引用字段有高效索引（通常是主键或唯一索引）
- 批量导入前可临时禁用外键检查：
SET FOREIGN_KEY_CHECKS = 0，但之后得人工核对数据一致性 - 分库分表后外键基本失效——跨库无法约束，别硬套
触发器无法替代外键的声明式约束能力
触发器（BEFORE INSERT / BEFORE UPDATE）能做外键做不到的事，比如调用函数、写日志、改其他表；但它不能阻止违反参照完整性的操作，除非你手动 ROLLBACK。而且触发器逻辑藏在数据库里，应用层看不见，排查问题时容易漏掉。
使用场景：需要在关联变更时同步更新统计字段（如商品表的 sales_count），或记录操作上下文（谁、何时、通过什么接口改的）。
- 触发器里的
SELECT可能引发死锁，尤其读取同一张被修改的表时 - MySQL 5.7+ 不支持在触发器里直接修改触发它的表（
Can't update table 'xxx' in stored function/trigger） - 触发器不继承外键的级联行为（
ON DELETE CASCADE），得自己实现，容易漏 case
高并发写入下，外键和触发器都可能成为瓶颈
两者都会增加单条语句的执行路径长度。外键是引擎层强校验，触发器是用户逻辑，但都发生在事务内，锁持有时间变长。压测中常见表现：QPS 上不去、innodb_row_lock_time_avg 突增、慢查询日志里大量 INSERT ... SELECT 卡在锁等待。
参数差异：innodb_lock_wait_timeout 默认 50 秒，但业务通常等不了这么久；而触发器执行超时不会报错，只会让事务变慢，更难定位。
- 如果业务能接受最终一致性（比如订单和用户关系允许短暂不一致），优先把约束提到应用层 + 异步校验
- 避免在触发器里调用存储过程或访问远程服务——网络延迟会直接拖垮整个事务
- 外键的
ON UPDATE CASCADE在更新主键时风险极高，生产环境几乎不用
真正该纠结的不是“选哪个”，而是“要不要在数据库层做这个事”
外键和触发器都是把业务规则耦合进数据库，好处是强保障，坏处是灵活性差、演进成本高。很多团队踩过坑才发现：一个 ALTER TABLE ... DROP FOREIGN KEY 可能要锁表几分钟，而一个误写的触发器能让所有写请求 hang 住。
复杂点在于——约束的位置决定了出错时的责任归属。外键报错是数据库明确拒绝，触发器报错是逻辑失败，而应用层绕过两者写的脏数据，谁都兜不住。
最容易被忽略的地方：备份恢复后外键约束默认启用，但触发器状态取决于 mysqldump 是否加了 --triggers 参数；少一个选项，上线就丢逻辑。
