主备切换后触发器不执行，先查SELECT @@sql_log_bin;返回值是否为1；若为0则不写binlog，但触发器仍可能静默执行；再比对主从SHOW CREATE TRIGGER定义，重点核对DEFINER、SQL SECURITY、字符集及非确定性函数使用。
主备切换后触发器不执行？先查 @@sql_log_bin 运行时值
从库上触发器“没运行”，往往不是被禁用了，而是当前会话根本没写 binlog —— 但触发器仍可能执行。关键看 SELECT @@sql_log_bin; 返回值：1 表示会记录 binlog（也意味着触发器默认参与复制逻辑），0 表示不记 binlog（触发器仍可能运行，但变更不会同步）。别只改配置文件，必须登录从库实查这个变量。常见误操作是切换后忘记检查，结果误判为“触发器失效”，其实是它静默执行了但没进 relay log。
触发器定义主从不一致？用 SHOW CREATE TRIGGER 逐字比对
主从触发器行为不同，80% 源于定义差异。在主库和从库分别执行 SHOW CREATE TRIGGER trigger_name;，重点核对三项：
-
DEFINER用户是否存在、是否有TRIGGER权限（从库缺用户会导致触发器加载失败，SHOW TRIGGERS可能直接不显示） -
SQL SECURITY是DEFINER还是INVOKER（DEFINER下从库以定义者身份执行，权限不足就静默失败） - 字符集、
DELIMITER、注释内容是否完全一致（某些 MySQL 版本因注释差异导致解析失败）
即使 binlog_format=ROW，这些写法仍导致主从偏差
ROW 模式只记录最终行变更，不保证触发器内部逻辑在主从上结果一致。以下写法必须重构：
- 调用非确定性函数：
UUID()、NOW()、SYS_DATE()—— 主从时间/随机种子不同，结果必然不同 - 访问临时表或用户变量（如
@tmp_var）—— 从库没有对应上下文，执行失败或跳过 - 嵌套存储过程且含
SELECT ... INTO或游标 —— ROW 模式不捕获中间查询，只记录最终 DML，逻辑链断裂
正确做法是把这类逻辑提到应用层生成后再传入，或改用 NEW.field := DEFAULT(field) 让 MySQL 自动填充。
内存表（ENGINE=MEMORY）触发的 1032 错误怎么救？
主库对 MEMORY 表执行 DELETE，binlog 却以 STATEMENT 格式记录（即使全局设了 ROW），从库重启后内存清空，回放时找不到记录就报 Can't find record in xx, Error_Code: 1032。这不是配置问题，是引擎特性陷阱：
- 紧急跳过不可取：
SET GLOBAL sql_slave_skip_counter = 1已弃用，且跳过会破坏事务一致性 - 安全做法是重建数据：在新主库导出
mysqldump -h new_master -uuser -p db table > table.sql，再导入到新从库 - 根治方案是避免在复制链路中使用 MEMORY 表；必须用时，确保主从同时重启（不现实），或改用
TEMPORARY TABLE+ 应用层控制生命周期
最易被忽略的是：内存表问题在主备切换前可能毫无征兆，一旦切换+重启，立刻暴露。排查时别陷在 binlog_format 或 GTID 里打转，先看报错表的 ENGINE 类型。
