大型电商系统慎用SQL触发器，因其违背高并发、可观测、易回滚、强协同原则：数据流从应用层显式驱动退化为数据库隐式扩散，导致路径不可见、批量性能断崖下跌、跨服务事务失控、运维迁移成本激增。
大型电商系统慎用 SQL 触发器，根本原因不是它“不能用”，而是它天然违背高并发、可观测、易回滚、强协同的系统设计原则——一旦引入，数据流就从“应用层显式驱动”退化为“数据库隐式扩散”，后续所有运维、扩容、排查、迁移动作都会多一层不可控。
触发器让数据变更路径不可见
电商系统里一次 UPDATE orders SET status = 'shipped'，表面看只是改个状态，但如果该表上有 3 个触发器（更新物流表、扣减库存、写审计日志），实际执行链路会变成：
- 原始语句 → 触发器 A（查
inventory行锁）→ 触发器 B（INSERT 到logistics_events）→ 触发器 C（UPDATEuser_stats） - 而这些中间步骤不会出现在应用日志、APM 链路追踪或慢 SQL 报警中
- DBA 看到的是“一条 UPDATE 耗时 800ms”，但无法快速判断是主表索引问题，还是触发器 B 的
logistics_events表没加索引导致全表扫描
更麻烦的是：这些触发器可能分散在不同数据库实例（比如日志表在从库），而监控工具只抓主库 DML，等于关键环节直接隐身。
批量操作时性能断崖式下跌
大促期间常见 INSERT INTO orders SELECT ... FROM staging_orders 导入 5 万单。如果订单表有行级 AFTER INSERT 触发器：
- MySQL/PostgreSQL 默认按行触发，5 万次重复执行相同逻辑（哪怕只是 INSERT 一条日志）
- SQL Server 若未显式关闭
RECURSIVE_TRIGGERS，且触发器里又 UPDATE 同一表，可能意外递归上千层 - 所有触发器内查询必须走索引——但线上环境经常漏建
WHERE order_id = NEW.order_id对应的索引，结果每次触发都扫全表inventory
实测案例：某电商在订单触发器中查 sku_info 表获取类目 ID，未加索引，单行触发耗时 12ms；批量导入 1 万单后，总耗时从 1.3s 涨到 127s，直接拖垮下游结算任务。
跨服务协作时事务边界失控
电商典型流程是“下单 → 扣库存 → 发通知 → 更新用户积分”，看似连贯，但触发器会强行把这四步塞进一个数据库事务：
- 若触发器里调用
CALL send_sms_proc(@mobile)，而短信服务超时，整个下单事务回滚，用户看到“下单失败”，但库存其实已扣（因扣库存在触发器外完成） - 更隐蔽的是：ORM 框架（如 MyBatis Plus）的乐观锁字段（
version）和触发器对同一行的 UPDATE 冲突，导致版本号跳变、重试逻辑失效 - 分布式事务场景下（如 Seata），触发器操作完全游离于 AT 模式之外，TCC 的 Confirm/Cancel 无法覆盖其副作用
这类问题上线后极难复现——测试环境通常单线程跑单条数据，而生产是并发 + 批量 + 网络抖动，触发器成了压垮一致性的最后一根稻草。
上线与迁移时维护成本指数级上升
触发器不进 Git、不走 CI/CD、不随应用发布，却直接影响业务行为：
- 新环境初始化数据库时，DBA 可能漏执行
CREATE TRIGGER脚本，导致“功能测试通过，生产数据错乱” - 灰度发布时，旧版应用连老库（有触发器），新版应用连新库（无触发器），两边数据状态分裂
- 想禁用某个触发器临时排查问题？得执行
DISABLE TRIGGER或DROP TRIGGER，而这操作本身需要 DBA 权限、可能触发锁表，不敢轻易动
最常被忽略的一点：很多电商用分库分表中间件（如 ShardingSphere），而触发器只作用于物理单表——你在逻辑表 orders 上定义的触发器，实际只生效在 orders_00，其他分表完全不受控。
