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

MySQL 触发器执行时使用的是 DEFINER 指定用户的权限。若显式声明 CREATE DEFINER = CURRENT_USER，则按调用者权限执行；若未显式指定，系统会默认使用创建者账号作为 DEFINER。这一行为既不会自动继承创建者当前权限，也不会主动降权，同时也不受 SUPER 权限相关开关影响。

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

MySQL 触发器在执行过程中，默认按照触发器定义中的 DEFINER 用户身份运行。若创建触发器时没有显式指定 DEFINER，MySQL 会自动将当前创建者账号，例如 'dba'@'localhost'，写入为默认 DEFINER。此后所有触发行为，都会基于该账号所拥有的权限执行。

也就是说，即使当前执行 UPDATE users 的是普通业务账号 'app_rw'@'%'，只要该触发器的 DEFINER 被设置为 'root'@'localhost'，那么触发器内部的 INSERT INTO audit_log 仍然能够正常执行。即便 app_rw 本身没有被授予 INSERT 权限，执行结果也不会因此改变。

这并不是漏洞，而是 MySQL 的既定设计。但在实际使用中，如果 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，并确保调用者账号仅拥有完成业务所需的最小权限。