大型电商系统慎用sql触发器，因其将跨服务业务逻辑（如扣库存）隐式绑定在数据库层，破坏微服务自治性，导致事务边界失控、服务治理失效、监控盲区及迁移风险。
触发器把业务逻辑钉死在数据库层
微服务强调每个服务自治，数据私有、边界清晰。但一旦在订单库加一个 AFTER INSERT 触发器去自动更新库存表，就等于把“扣减库存”这个本该属于库存服务的职责，硬塞进了订单服务的数据存储层。应用代码看不到这个逻辑，日志里不记录，链路追踪里不出现，可它真实参与了跨服务的数据变更。
跨服务数据变更绕过API网关和限流熔断
库存服务暴露的 /api/stock/deduct 接口可以做参数校验、流量控制、降级兜底；而触发器调用的 UPDATE inventory SET qty = qty - 1 WHERE sku_id = ? 直接走数据库连接池，不受任何服务治理策略约束。大促时订单洪峰涌来，触发器批量执行，瞬间打爆库存库的连接数或锁表，但监控系统只看到“订单写入慢”，根本发现不了库存服务已被隐式压垮。
事务边界被触发器悄悄拉长
订单服务开启事务插入 orders 表，触发器顺带更新 inventory 表——这两个操作共享同一个事务上下文。这意味着：
- 库存表上的索引缺失、慢查询、行锁等待，会直接拖住整个订单事务
- 如果库存服务本身是独立部署的，它的数据库连接、重试策略、超时设置全被绕过
- 更危险的是，若触发器还调用了另一个库的日志表，就构成跨库事务，MySQL 无法保证原子性，只能靠应用层补偿，但触发器根本不支持补偿逻辑
服务演进时触发器成“隐形债”
当团队决定把库存功能拆成独立微服务，并迁移到 PostgreSQL 时，原 MySQL 订单库里的触发器立刻失效。没人记得它存在，直到上线后发现订单状态更新了但库存没扣——因为迁移脚本只导了表结构和数据，漏掉了 SHOW CREATE TRIGGER 的输出。这类逻辑散落在数据库里，既不能版本控制，也无法做单元测试，比硬编码在 Java 类里更难发现、更难清理。
微服务里最危险的耦合，不是接口调用，而是那些你看不见、管不住、改不了的隐式依赖。SQL 触发器正是这种耦合的典型载体——它不走注册中心，不发消息，不记 traceId，却实实在在地把两个服务的命运绑在了一条事务链上。
