根本原因是分布式架构下触发器与事务一致性、锁范围和执行可观测性天然冲突：跨分片触发器破坏2PC边界，导致事务延长、回滚风险升高；行级锁无法跨节点收敛易引发隐式死锁；触发器定义无法自动同步至各物理分片，运维与备份恢复风险高。
云原生数据库（如 PolarDB-X）对 SQL 触发器的限制比单机 MySQL 更严，根本原因不是“不想支持”，而是分布式架构下触发器天然与事务一致性、锁范围和执行可观测性冲突。
触发器在分布式事务中会破坏两阶段提交（2PC）边界
单机数据库里，触发器和主 DML 共享同一事务上下文，回滚/提交是原子的；但在 PolarDB-X 这类分库分表系统中，一个 INSERT 可能跨多个物理分片，而触发器逻辑若涉及另一张表（比如审计日志表），该表可能落在不同节点上——此时触发器执行会强行把原本可异步处理的逻辑塞进 2PC 流程，导致：
- 事务协调器必须等待所有分片上的触发器都完成，大幅延长事务持有时间
- 某个分片上触发器失败（如网络抖动、目标表无索引导致超时），整个分布式事务回滚，但部分分片的主 DML 可能已落盘（PolarDB-X 的 XA 事务存在“prepare 成功但 commit 失败”的中间态）
- 官方明确不支持跨库触发器调用，
AFTER INSERT ON orders里写INSERT INTO audit_log若audit_log不在同个逻辑库，直接报错ERROR 1105 (HY000): Unsupported operation: cross-database trigger
行级锁无法跨节点收敛，极易引发隐式死锁
触发器内访问其他表时，会继承原始事务的锁粒度。在单机库中，最多锁几行；但在分布式场景下，一次 UPDATE 触发的触发器若要更新库存表，而库存按商品 ID 分片，就可能同时锁住多个物理节点上的不同行——这些锁由不同节点的本地事务管理器维护，全局死锁检测成本高、响应慢。
- PolarDB-X 默认关闭嵌套事务传播，
UPDATE触发器里再UPDATE同一逻辑表，可能被路由到不同分片，出现“本分片成功、他分片失败”状态不一致 - 监控工具（如
SHOW PROCESSLIST）只显示当前节点的锁等待，看不到跨节点阻塞链，排查时只能靠日志拼接 - 官方开发指南明确限制：触发器内禁止
SELECT ... FOR UPDATE或任何显式加锁语句，否则ERROR 1205 (HY000): Deadlock found when trying to get lock概率陡增
触发器定义无法随分片自动同步，运维风险放大
单机库中 CREATE TRIGGER 是原子操作；但 PolarDB-X 的触发器只存在于逻辑库元数据中，实际执行时需下发到每个参与分片。一旦某分片升级失败、或 DDL 同步延迟，就会出现“部分节点有触发器、部分没有”的撕裂状态。
- 执行
SELECT * FROM information_schema.triggers只返回逻辑层定义，不反映各物理节点真实状态 - 扩容新节点后，触发器不会自动创建，必须手动在每个分片上重复执行
CREATE TRIGGER（但 PolarDB-X 实际不开放物理节点直连，只能通过 DDL 代理下发，且成功率不可控） - 备份恢复时，逻辑备份（mysqldump）默认不导出触发器，容易遗漏——而 PolarDB-X 的物理备份又不包含逻辑对象定义
真正麻烦的不是“不能用”，而是“看似能用，却在流量高峰或节点异常时突然失效”。比如一个用于记录变更时间的简单触发器，在测试环境跑得好好的，上线后某次分片网络分区，它开始静默跳过执行，没人知道数据已经不再准确。这种问题没法靠加监控解决，因为触发器本身不产生可观测事件。
