STATEMENT模式下触发器必然导致主从双写或漏写，因binlog仅记录原始SQL，从库重放时重复执行触发器逻辑，若含NOW()、USER()等非确定函数则结果不一致。
STATEMENT模式下触发器必然双写或漏写
MySQL默认binlog_format=STATEMENT时，只记录原始SQL语句，比如INSERT INTO orders，完全不记录触发器是否被触发、触发几次、做了什么。从库重放时，会重新执行这条语句——连带触发器逻辑一起再跑一遍。如果触发器里用了NOW()、USER()、@session_var，结果就和主库对不上。
典型现象包括：ERROR 1062（唯一键冲突）、日志表多出几行、计数字段偏差。更麻烦的是，这类错误往往不报在SHOW SLAVE STATUS里，SQL线程显示“Executed”，但数据已经裂开。
常见误操作：
- 以为
SET sql_log_bin = 0能在从库禁用触发器——它只关binlog写入，不影响触发器本身执行 - 在从库删掉触发器指望“绕过去”——主库的变更仍会按原逻辑写入，只是从库没做对应副作用，导致辅助表缺失
- 依赖
replicate_ignore_table过滤日志表——若触发器更新的是同一张表的其他字段，这个配置根本不起作用
ROW模式下触发器仍可能破坏一致性
binlog_format=ROW看似安全，因为它只记录“哪一行变成什么样”，不重放触发器逻辑。但只要触发器干了这三件事，主从照样偏离：
调用非确定性函数：UUID()、RAND()、SYSDATE()——主库生成的值不会进binlog，从库重放时用本地时间/随机数补全，必然不同
操作临时表或用户变量：CREATE TEMPORARY TABLE tmp_x或SET @tmp_id = LAST_INSERT_ID()——从库没有这些上下文，执行直接失败或静默跳过
更新其他表：INSERT INTO audit_log——ROW日志只包含主表变更，audit_log的写入不会进binlog，从库永远缺失
验证方法：SHOW CREATE TRIGGER t1_ins后人工搜索UUID(、NOW(、SELECT ... INTO等关键词；再查SHOW BINLOG EVENTS，看是否混有Query_log_event（说明已退化为STATEMENT）
从库是否执行触发器取决于运行时状态
别只看my.cnf里的配置，真正起效的是当前会话的运行时值：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
SELECT @@sql_log_bin返回1：当前会话会写binlog，触发器默认执行；返回0：不写binlog，但触发器仍可能运行（除非被权限或DROP拦住）
SHOW CREATE TRIGGER t1_ins查SQL SECURITY：如果是DEFINER，从库会以定义者身份执行——若该用户在从库不存在，或没TRIGGER权限，就会静默失败或报错ERROR 1449
关键点：
-
DEFINER用户必须在从库存在且有TRIGGER权限，否则SHOW TRIGGERS可能根本查不到这个触发器 - 从库
read_only=ON时，DEFINER用户若没SUPER权限，触发器更新会直接报错 -
log_bin_trust_function_creators=1不是解药——它只绕过创建检查，不解决执行时的环境差异
真正可靠的解法是移除触发器副作用
把触发器逻辑移到应用层是最稳妥的：
时间戳、唯一ID等由应用生成后传入，避免NOW()、UUID()在从库重复计算
跨表更新（如订单+积分+通知）拆成应用内事务，用消息队列或本地事件保证最终一致性
简单字段补全（如status根据created_at自动设为'pending'）改用GENERATED COLUMN，不依赖运行时逻辑
ROW模式只是让问题更隐蔽，而不是解决它。只要触发器还访问外部状态、调用非确定函数、写其他表，主从数据偏差就是时间问题——尤其当主从系统时钟误差超过毫秒级、或chrony同步未启用时，NOW()类偏差会立刻暴露。
