触发器让数据变更路径彻底不可见，因其隐式执行库存扣减、风控校验、日志写入等操作，不暴露于应用日志、APM或慢SQL监控中；批量操作时放大为O(n)性能问题且无法通过索引优化；在分库分表、读写分离、多活架构下天然失效或引发重复执行；调试困难、迁移成本高、多人协作难管理，最终使数据流沦为黑盒。
触发器让数据变更路径彻底不可见
电商或支付系统里一次 UPDATE orders SET status = 'paid'，表面只是改个状态，但背后可能隐式触发库存扣减、风控校验、日志写入三张不同表的操作。这些动作不会出现在应用日志、APM链路追踪、慢SQL监控里——DBA看到的永远只是一条“耗时 620ms 的 UPDATE”，根本无法定位是主表索引问题，还是触发器里查 sku_info 没走索引导致全表扫描。
更麻烦的是：如果日志表在从库、风控表在分库中间件后端，这些触发路径直接脱离监控体系。你查 performance_schema.events_statements_history_long，SQL_TEXT 字段还被截断，连完整逻辑都拼不全。
批量操作时性能断崖下跌且无法优化
大促期间执行 INSERT INTO orders SELECT * FROM staging_orders 导入 5 万单，哪怕触发器只做一条 INSERT INTO audit_log，MySQL 也会按行触发 5 万次。这不是“慢查询”，而是把 O(1) 操作放大成 O(n)，且无法通过加索引、调优执行计划缓解。
常见踩坑点：
- 触发器内
SELECT COUNT(*) FROM config—— 每次插入都查配置表，变成 5 万次无谓查询 -
AFTER INSERT写日志表，但该表没主键也没索引 ——INSERT退化为全表扫描式写入 - 多个触发器叠加（BEFORE + AFTER），错误传播路径模糊，
ERROR 1422只报“不允许提交”，不指明是哪个触发器干的
分布式架构下触发器天然失效
一旦引入分库分表或读写分离，触发器就变成废代码：
- ShardingSphere/MyCat 不解析触发器内部 SQL，硬编码表名如
UPDATE order_001会绕过分片路由规则 - 触发器只在主库执行，从库回放的是原始 DML ——
AFTER INSERT生成的审计记录在从库上根本不存在 - 多活架构下双向同步，同一触发器可能在两边重复执行，造成计数翻倍、状态错乱
-
ERROR 1442在分布式场景更难规避：触发器想查另一个分片的user_balance表？跨库查询直接报错，且错误常被静默吞掉
调试和迁移成本远高于收益
MySQL 没有触发器断点、不支持单步执行、运行时不能打印变量值。唯一“调试”方式是往独立日志表硬塞记录，而这个日志表本身又可能成为新瓶颈。
真实运维困境：
- 想查某次更新为什么慢？得先跑
SELECT * FROM INFORMATION_SCHEMA.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'orders'，再人工翻定义，再加日志，再重放 —— 整个链路无法自动化 - 从 MySQL 迁到 TiDB 或 PostgreSQL，所有触发器全部重写，没有可移植性
- 多人协作时，业务逻辑散落在应用代码 + 多个触发器里，版本管理靠人肉同步，Git 里根本看不到数据库层变更
真正麻烦的不是写不出来，是它把最该清晰的数据流，变成了藏在数据库深处的黑盒——出问题时既看不到它在哪卡住，也很难证明它拖慢了谁。
