触发器不是一致性增强器，而是单点故障放大器；它无法覆盖所有写入路径、调试可观测性差、并发锁行为不可控，且在强一致场景下更脆弱。
因为触发器把业务逻辑锁死在数据库里，而应用层能控制事务、可观测、可测试、可降级——MySQL 官方不反对用触发器，但明确反对把它当“业务逻辑兜底方案”。
触发器无法覆盖所有写入路径
触发器只响应标准 INSERT/UPDATE/DELETE 语句。以下操作完全绕过它：
- 应用调用存储过程批量更新（
CALL batch_update_orders()），而该过程没显式触发对应逻辑 - DBA 手动执行
UPDATE inventory SET stock = stock - 1 WHERE sku = 'A001' - ETL 工具用
LOAD DATA INFILE或COPY导入数据，默认跳过触发器 - CDC 工具（如 Debezium）同步写入目标库，源库触发器毫无作用
一旦存在任一绕过路径，数据就立刻不一致。你无法靠“加个触发器”解决一致性问题，只能靠“所有写入必须走同一入口”。
触发器调试和可观测性几乎为零
你没法在触发器里打日志、设断点、mock 依赖、跑单元测试。常见故障现象：
-
ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger—— 报错不指明是哪个触发器、哪一行代码引发的 -
SHOW PROCESSLIST只显示Executing trigger，不标出触发器名 -
EXPLAIN INSERT INTO orders完全不展示触发器内任何 SQL，性能瓶颈藏得极深 - 想查某张表有没有触发器？得手动跑
SELECT * FROM INFORMATION_SCHEMA.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'orders'
而应用层日志、链路追踪、SQL 监控、Mock 测试全部可用，排查效率差一个数量级。
并发下锁行为不可控且极易死锁
触发器逻辑运行在主 DML 的同一事务中，锁持有时间被它直接延长。典型翻车场景：
-
BEFORE UPDATE里执行SELECT COUNT(*) FROM log_table WHERE status = NEW.status，但log_table缺少(status, created_at)复合索引 → 全表扫描 + 行锁阻塞其他写入 - AFTER INSERT 触发器执行
UPDATE users SET last_order_time = NOW() WHERE id = NEW.user_id，同时另一条业务 SQL 先锁users再锁orders→ 死锁 - 空触发器本身就有 0.1–0.3ms 固定开销；含
SELECT ... FOR UPDATE的触发器，5ms 就能让平均锁等待翻倍
这些锁问题不会出现在慢查询日志里，只体现在 innodb_row_lock_waits 和 Threads_running 指标上，等你发现时系统已卡住。
真正需要强一致的地方，触发器反而更脆弱
比如订单状态流转校验（pending → confirmed），看似适合用 BEFORE UPDATE 做判断，但实际风险更大：
- 应用读取记录后做判断，触发器悄悄改了
NEW.status，应用仍按旧值执行后续逻辑 → 状态错乱 - 校验失败时若没写
SIGNAL SQLSTATE '45000'，而是只写日志或插入 error_log 表 → 事务照样提交，数据已错 - 触发器里调用自定义函数（如
GET_CURRENT_USER_RANK()），函数内部无索引扫描、无缓存、无法监控 → 耗时波动大，拖垮整条 SQL
最易被忽略的一点：触发器不是“一致性增强器”，它是“一致性单点故障放大器”——它让所有写入路径都依赖同一个隐式、不可测、难运维的钩子。
