主从复制中触发器会破坏数据一致性，因binlog不记录触发器执行元信息，导致从库重复执行或漏执行；需统一ROW格式、限制触发器仅操作当前表、排除辅助表同步，并优先采用业务层替代方案。
主从复制中触发器会破坏数据一致性
MySQL 主从复制默认是基于 binlog 的逻辑复制，而触发器在从库执行时可能产生意料之外的副作用。最典型的问题是：主库执行一条 INSERT，触发器自动写入另一张表；从库重放这条语句时，如果也执行触发器，就可能导致重复插入、计数错乱或违反唯一约束。
根本原因在于：触发器属于「语句级副作用」，而 binlog 默认记录的是原始语句（STATEMENT 格式）或行变更（ROW 格式），但都不包含触发器是否该在从库执行的元信息。
-
STATEMENT模式下，从库会重新执行整个语句 + 触发器，极易引发双写 -
ROW模式下看似安全，但若触发器修改了其他表（非当前 DML 涉及的表），这些变更不会被记录进 binlog，从库就完全缺失这部分数据 - 即使关闭从库触发器（
slave_sql_verify_checksum=OFF无效；真正有效的是sql_log_bin=0或设置log_bin_trust_function_creators=1配合权限控制，但治标不治本）
如何判断触发器是否被从库执行
关键看从库的 binlog_format 和触发器定义中的 SQL SECURITY 属性，但更直接的方式是查 SHOW SLAVE STATUS\G 中的 Seconds_Behind_Master 是否异常跳变，再结合错误日志搜 ERROR 1062、ERROR 1452 等。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 在从库执行
SELECT @@sql_log_bin;—— 若为1，说明触发器默认会被执行（除非显式关掉） - 检查触发器定义：
SHOW CREATE TRIGGER xxx;，重点关注DEFINER用户是否有TRIGGER权限，以及是否用了SQL SECURITY DEFINER（从库会以定义者身份执行，权限不足则报错） - 临时禁用从库触发器：在从库 session 中执行
SET sql_log_bin = 0;，再执行 DML 测试，但注意这会影响所有 binlog 写入，仅限诊断
安全使用触发器的三个硬性前提
不是不能用，而是必须满足以下全部条件，否则同步风险极高：
- 主从必须统一使用
ROW格式（binlog_format=ROW），且触发器只操作当前语句涉及的同一张表（比如自增字段补全、状态字段更新） - 触发器内部禁止出现
INSERT/UPDATE/DELETE其他表、调用存储函数、访问临时表等「跨表/跨上下文」操作 - 从库必须设置
replicate_ignore_table或replicate_wild_ignore_table排除触发器所操作的辅助表（如果真有独立日志表），否则主从表结构或数据量会逐渐偏离
替代方案比硬扛触发器更可靠
业务层写入前预处理、应用内事件监听、或者用 GENERATED COLUMN 替代简单计算逻辑，都比依赖触发器稳妥。MySQL 8.0+ 的 DATA CHANGE REPLICATION（DCR）仍不支持触发器透传，所以没有银弹。
最容易被忽略的一点：即使你确认触发器「只读」或「幂等」，只要它访问了主库存在但从库缺失的表（比如监控表、配置表），就会导致从库 SQL 线程直接停止——错误信息通常是 Table 'xxx.yyy' doesn't exist，而不是触发器本身报错。
