触发器执行时用的是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 的那个账号的权限去执行内部操作。
- 建触发器时必须写明：
CREATE DEFINER = CURRENT_USER TRIGGER ... - 不能省略
DEFINER字段，否则 MySQL 自动填入当前登录用户（通常是高权账号） -
CURRENT_USER是会话级函数，返回实际连接认证的账号，不是USER()那种带主机名的字符串 - 如果触发器里要查其他表或调用函数，调用者账号必须已拥有对应
SELECT、EXECUTE等权限，否则触发器直接报错失败
常见绕过陷阱和检查要点
即使写了 DEFINER = CURRENT_USER，仍可能因配置或语法问题失效：
- MySQL 5.7+ 默认启用
sql_mode = 'NO_ENGINE_SUBSTITUTION'，但若服务器启用了log_bin_trust_function_creators = OFF，且触发器内调用自定义函数，仍需额外授予EXECUTE权限——这跟DEFINER无关，是函数本身要求 -
SHOW CREATE TRIGGER trigger_name必须看到第一行明确写着DEFINER = CURRENT_USER，而不是DEFINER = 'root'@'%'或空缺 - 用
mysqldump导出再导入触发器时，默认会带上原DEFINER，容易把高权定义带进生产环境 - 某些 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，以及确保调用者账号权限刚好够用、不多不少。
