触发器在双机热备中不可用于同步或复制，仅限主库内做写入拦截和本地校验；从库只读且不执行触发器，其副作用（如日志、报错）不会同步，还可能因STATEMENT复制引发错误中断。
双机热备场景下，触发器不能用于同步或复制，它只适合在单库内做写入拦截和本地一致性校验；热备本身靠主从复制机制保障，触发器加进去反而可能破坏复制链路或引发死锁。
触发器在热备环境里根本跑不起来
MySQL 主从、PostgreSQL 流复制、SQL Server Always On 等热备方案中，从库默认是只读的。而触发器（尤其是 BEFORE INSERT 或 BEFORE UPDATE）只能在写入发生的节点上执行——也就是主库。从库不会触发任何触发器逻辑，也不会回放触发器产生的副作用（比如 SIGNAL 报错、INSERT 日志表等）。
- 你在主库建了
BEFORE UPDATE触发器去校验订单状态变更，从库完全感知不到，也不会拦截非法更新 - 如果触发器里写了
INSERT INTO audit_log，这条日志只会进主库，从库没有，日志就断层 - 更危险的是：某些触发器逻辑（如查同一张表、调用函数、更新其他表）在主库可能正常，但一旦被复制到从库（尤其用了
STATEMENT格式），可能因执行上下文差异直接报错，中断复制
真正该在校验的位置：主库约束 + 从库定期比对
热备数据一致性校验不是靠“两边都跑触发器”，而是分层做：主库用约束守住入口，从库用 SQL 主动抽查结果。触发器只在主库用于无法用约束表达的轻量业务规则（如状态流转限制），且必须避开跨表查询和写操作。
-
CHECK约束优先：比如status IN ('draft', 'paid', 'shipped')，MySQL 8.0.16+ 和 PostgreSQL 原生支持，零开销，主从一致生效 - 外键用
ON UPDATE CASCADE替代触发器补救：避免主表改了 ID、从表没同步导致数据断裂 - 从库校验用只读 SQL：比如每天凌晨跑一次
SELECT COUNT(*) FROM orders WHERE total_amount ，结果为 0 才算通过；这类语句可安全在从库执行，不干扰复制 - 若要对比主从数据差异，用
CHECKSUM_AGG(CHECKSUM(...))（SQL Server）或MD5(GROUP_CONCAT(... ORDER BY ...))（MySQL），但注意 NULL 处理和列顺序
硬要在主库加触发器？这三条红线不能碰
如果业务确实需要在主库用触发器做校验（比如禁止 status 从 'shipped' 回退），必须确保它不破坏热备稳定性：
- 别查从库不存在的表：触发器里
SELECT只能查当前库已有表，且避免SELECT ... FROM same_table（MySQL 会报错） - 别写其他表：
INSERT INTO log_table看似方便，但日志表若没在从库建好，或复制过滤规则漏掉它，就会丢数据或中断复制 - 错误必须用
SIGNAL SQLSTATE '45000'（MySQL）或RAISERROR（SQL Server）主动抛出，不能依赖隐式约束报错——否则主库拦住了，但从库可能因复制延迟或格式问题漏检
热备下的校验本质是“主库守门 + 从库抽查”，触发器只是主库守门工具之一，且能力有限。最容易被忽略的点是：从库的只读属性决定了它无法运行任何写入型校验逻辑，所有依赖触发器副作用（如写日志、改状态）的设计，在热备架构里天然失效。
