如何避免MySQL触发器以高权限账号执行

触发器执行时用的是DEFINER指定用户的权限——若显式声明CREATE DEFINER = CURRENT_USER，则按调用者权限执行；否则默认使用创建者账号权限，不继承、不降权，且不受SUPER权限开关影响。

触发器执行时用的是谁的权限

MySQL 触发器运行时，不继承创建者的 DEFINER 权限，也不自动降权——它默认以触发器定义中 DEFINER 指定的用户身份执行。如果没显式声明 DEFINER，MySQL 会用当前创建者（如 'dba'@'localhost'）作为默认 DEFINER，后续所有触发动作都按这个账号的权限跑。

这意味着：哪怕你用普通应用账号 'app_rw'@'%' 执行 UPDATE users，只要触发器 DEFINER 是 'root'@'localhost'，里面写的 INSERT INTO audit_log 就能成功，哪怕 app_rw 根本没被授过 INSERT 权限。

这不是漏洞，是设计行为。但正是这点，让触发器成了高权限“后门”——尤其当 DEFINER 被设成超级账号时。

如何强制触发器用调用者权限运行

唯一可靠方式是显式把 DEFINER 设为 CURRENT_USER，这样触发器就只能用发起 DML 的那个账号的权限去执行内部操作。

1. 建触发器时必须写明：CREATE DEFINER = CURRENT_USER TRIGGER ...
2. 不能省略 DEFINER 字段，否则 MySQL 自动填入当前登录用户（通常是高权账号）
3. CURRENT_USER 是会话级函数，返回实际连接认证的账号，不是 USER() 那种带主机名的字符串
4. 如果触发器里要查其他表或调用函数，调用者账号必须已拥有对应 SELECT、EXECUTE 等权限，否则触发器直接报错失败

常见绕过陷阱和检查要点

即使写了 DEFINER = CURRENT_USER，仍可能因配置或语法问题失效：

1. MySQL 5.7+ 默认启用 sql_mode = 'NO_ENGINE_SUBSTITUTION'，但若服务器启用了 log_bin_trust_function_creators = OFF，且触发器内调用自定义函数，仍需额外授予 EXECUTE 权限——这跟 DEFINER 无关，是函数本身要求
2. SHOW CREATE TRIGGER trigger_name 必须看到第一行明确写着 DEFINER = CURRENT_USER，而不是 DEFINER = 'root'@'%' 或空缺
3. 用 mysqldump 导出再导入触发器时，默认会带上原 DEFINER，容易把高权定义带进生产环境
4. 某些 ORM 或中间件（如 ProxySQL）可能改写 SQL 包裹层，导致实际执行用户与预期不符，建议在触发器开头加 INSERT INTO debug_log VALUES (CURRENT_USER(), NOW()); 实测验证

为什么不能依赖 SUPER 权限临时关闭触发器

有人想“先用 SUPER 登录，SET sql_log_bin = OFF 再操作”，以为能跳过触发器——但这是误解。

sql_log_bin = OFF 只影响 binlog 记录，不影响触发器执行。BEFORE/AFTER 触发器照样跑，只是不写日志而已。而且：SUPER 权限本身已被 MySQL 8.0+ 拆解，日常运维账号不该持有；一旦放开，反而扩大了攻击面。

真正可控的做法只有两个：严格控制 DEFINER，以及确保调用者账号权限刚好够用、不多不少。