触发器会破坏主从数据一致性，因binlog不记录其执行元信息，导致从库重复执行或漏执行；须统一ROW格式、限制触发器仅操作当前表，并优先采用业务层替代方案。
触发器执行发生在从库回放阶段，直接拖慢 SQL Thread
MySQL 主从复制中，SQL Thread 负责解析 relay log 并逐条重放事件。如果主库语句本身不带触发器，但从库表上定义了触发器，那它不会被复制过去——但反过来，**主库上的触发器会在主库执行时就完成，并写入 binlog**（取决于 binlog 格式）。关键点在于：触发器逻辑是否被记录进 binlog，决定了从库要不要再跑一遍。
常见错误现象是：主库执行一条 UPDATE 很快，但从库 Seconds_Behind_Master 突然跳涨，且 SHOW PROCESSLIST 显示 SQL Thread 正在执行类似 Updating 或 Trigger 的状态。
- 使用
STATEMENT格式时：触发器语句本身不记入 binlog，但触发器产生的副作用（如 INSERT 到另一张表）会被当作独立语句记录——这会导致主从行为不一致，且从库要多执行几条语句，延迟升高 - 使用
ROW格式时：触发器不被复制，但触发器修改的行变更会以“最终结果”形式写入 binlog；从库只重放行变更，不重新触发逻辑——这是安全的，但若触发器做了大量计算或调用了函数（如NOW(),UUID()），主库写入的行数据可能和从库实际生成的数据不一致，MySQL 会强制退化为STATEMENT模式记录，引发连锁延迟 - 触发器里含
SELECT ... FOR UPDATE或访问其他大表：这类操作在从库单线程回放时极易产生锁等待，阻塞后续所有事务
ROW 格式下触发器导致的隐式 STATEMENT 回退
MySQL 在 ROW 模式下发现某些语句“不可确定”（non-deterministic），会自动切换成 STATEMENT 记录，典型场景包括触发器中调用：NOW()、UUID()、USER()、子查询带 LIMIT、或触发器内更新了未在 binlog 中显式列出的表。
这种回退不是报错，也不会告警，但会导致：
- binlog 体积突增（尤其在批量更新时）
- 从库必须重新解析并执行原始 SQL，而非简单应用行变更
- 原本可并行的事务（如不同库的写入）因语句模式退化而被迫串行
验证方式：在主库执行 SHOW BINLOG EVENTS IN 'mysql-bin.000001' LIMIT 20;，观察事件类型是否混有 Query_log_event（STATEMENT）和 Table_map_log_event+Write_rows_log_event（ROW）。
如何判断触发器是不是延迟元凶
别猜，直接查从库正在回放什么：
- 在从库运行
SHOW SLAVE STATUS\G，确认Slave_SQL_Running_State是不是卡在Updating、System lock或Waiting for table metadata lock - 接着查
SELECT * FROM performance_schema.threads WHERE TYPE = 'BACKGROUND' AND NAME LIKE '%sql%';，看对应线程的PROCESSLIST_INFO是否包含触发器涉及的表名或关键词 - 临时关闭触发器对比（仅测试环境）：
SET GLOBAL log_bin_trust_function_creators = 1;+ 删除触发器后压测，观察Seconds_Behind_Master是否回落 - 检查主库 binlog 内容是否含非确定性函数：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | grep -A5 -B5 "NOW\|UUID\|USER"
真正有效的缓解手段不是禁用触发器，而是控制它的传播路径
触发器本身不是问题，问题在于它让从库承担了本该在主库完成的逻辑负担。最务实的做法是切断“触发器逻辑跨库执行”的可能性：
- 主库触发器只做轻量级日志记录（如写入 audit 表），避免跨表更新、远程调用、复杂计算
- 把业务侧需要的“联动更新”逻辑移到应用层，用事务包住主表更新 + 关联表更新，确保 binlog 记录的是明确的 ROW 变更
- 若必须用触发器，强制主库使用
ROW格式，并在触发器开头加IF @@server_id != 1 THEN ... END IF;（假设主库server_id = 1），防止从库误执行 - 升级到 MySQL 8.0+ 后，启用
WRITESET并行复制：SET GLOBAL binlog_transaction_dependency_tracking = 'WRITESET';，能部分抵消单触发器阻塞全局回放的问题
最容易被忽略的一点：即使你没写触发器，第三方中间件（如 ShardingSphere、Maxwell）或备份工具（xtrabackup）在恢复时也可能悄悄重建触发器——上线前务必核对从库表的 SHOW CREATE TABLE 输出。
