触发器“没反应”大概率是未被调用，主因有三：权限不匹配（definer权限不足）、sql_log_bin=0或binlog_format=statement导致跳过、触发器status为disabled；须查information_schema.triggers确认enabled状态，并验证definer权限与日志表独立性。
触发器“没反应”大概率不是代码写错了，而是它压根没被调用——常见原因就三个：权限不对、binlog关了或模式不对、触发器本身处于DISABLED状态。
先确认触发器是否真的存在且已启用
MySQL 不会告诉你触发器被禁用了，也不会出现在 SHOW TABLES 里。它只藏在系统表中。
- 执行
SELECT * FROM information_schema.TRIGGERS WHERE TRIGGER_NAME = 'your_trigger_name';，重点看STATUS字段：必须是ENABLED才算生效 - 如果值为
DISABLED，运行ALTER TRIGGER your_trigger_name ENABLE;（注意：MySQL 5.7 不支持该语法，只能DROP后重建） -
SHOW TRIGGERS LIKE 'table_name';更快，但只查当前数据库；跨库要先USE db_name
检查用户权限和 DEFINER 权限是否匹配
触发器执行用的是 DEFINER 用户的权限，不是你当前登录用户的权限。哪怕你是 root，只要定义时写了 DEFINER = 'appuser'@'%'，就只认 appuser 的权限。
- 查定义：
SHOW CREATE TRIGGER trigger_name;，看DEFINER是谁 - 查该用户权限：
SHOW GRANTS FOR 'appuser'@'%';，确认它对触发器内所有操作的表都有对应权限（比如 INSERT 到日志表，就得有INSERT ON sys_log.audit_log） - 特别注意：如果触发器里用了
NEW.col或OLD.col，而DEFINER没有对原表的SELECT权限，字段值可能读不到，导致逻辑静默失败
验证 binlog 和 sql_log_bin 是否干扰触发器执行
触发器本身不依赖 binlog，但在复制环境或开启 log_bin 后，binlog_format = STATEMENT 可能导致含 NOW()、UUID()、用户变量的语句被跳过，间接让触发器“失效”。
- 运行
SHOW VARIABLES LIKE 'log_bin';和SHOW VARIABLES LIKE 'binlog_format';，避免STATEMENT模式下使用非确定性函数 - 检查当前会话：
SELECT @@sql_log_bin;，结果必须为1；若为0，触发器不会写入 binlog，某些高可用组件可能误判状态，甚至跳过执行 - 别信“我只是本地开发”，有些 ORM 或连接池会默认设置
SET SESSION sql_log_bin = 0，得查应用层连接初始化逻辑
为什么加了日志表还是看不到记录？
写日志表是最直接的验证方式，但容易踩两个坑：日志表和主表同名/同库引发锁冲突，或者触发器根本没走到那行代码。
- 日志表必须完全独立：不要叫
users_log如果主表是users，更别建在同一个库下（除非你确认无跨表锁风险） - 日志语句放最开头：
INSERT INTO debug_log (msg) VALUES ('in_before_insert');，如果这行都没进，说明触发器压根没触发 - 如果进了日志但后续逻辑没生效，大概率是中间某条 SQL 报错被静默吞掉——立刻执行
SHOW WARNINGS;，它常比错误日志更快暴露真实问题（如Unknown column 'xxx'）
真正难排查的从来不是语法错误，而是那些“看起来成功了，其实什么都没干”的情况：权限缺位、sql_log_bin = 0 被会话级覆盖、DEFINER 对目标表没 SELECT 权限导致 NEW 字段为空……这些都不会报错，只会让逻辑中途消失。
