触发器执行时用的是定义者（DEFINER）的权限；默认SQL SECURITY为DEFINER，以创建者身份运行，不校验调用者权限，存在越权风险，而INVOKER模式则受当前用户权限约束。
触发器执行时用的是谁的权限？
MySQL 触发器在执行时不检查调用者的权限，而是严格依赖定义时指定的 SQL SECURITY 属性。默认是 DEFINER，意味着触发器以创建者（即 DEFINER 用户）的身份运行，哪怕当前执行 INSERT/UPDATE/DELETE 的用户只有最低权限，只要语句本身合法，触发器内部的 SQL 仍会以定义者权限执行。
这带来明显风险：一个低权限用户通过合法 DML 操作，可能间接触发高权限逻辑（如向审计表写入、调用 sys_exec() 插件、删日志表等）。
-
SQL SECURITY DEFINER：最常见，也最危险——只要定义者有权限，触发器就能越权操作 -
SQL SECURITY INVOKER：触发器内所有操作受当前执行用户的权限约束，更安全但可能因权限不足导致触发失败 - 定义者必须对触发器中涉及的所有表拥有对应权限（如触发器里有
INSERT INTO audit_log，定义者就得有audit_log的 INSERT 权限）
如何查出数据库里有哪些 DEFINER 是高危账户的触发器？
直接查 information_schema.TRIGGERS 表，重点关注 DEFINER 字段是否为 'root'@'%'、'admin'@'localhost' 等强权限账户，以及 EVENT_MANIPULATION 是否包含敏感动作（如 DELETE、TRUNCATE）。
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_MANIPULATION,
ACTION_STATEMENT, DEFINER
FROM information_schema.TRIGGERS
WHERE DEFINER LIKE '%root@%' OR DEFINER LIKE '%admin@%';注意：ACTION_STATEMENT 是原始 SQL 文本，需人工审查是否含危险函数（如 LOAD_FILE()、UNION SELECT ... INTO OUTFILE）、跨库操作或硬编码密码。
触发器里能绕过行级权限控制吗？
能，而且很彻底。MySQL 原生不支持行级访问控制（RLS），而触发器在服务端执行，完全不受客户端权限模型限制。例如：
- 某用户仅被授权查询
orders表中status = 'pending'的行（靠应用层过滤），但触发器若在AFTER INSERT中执行SELECT * FROM orders WHERE user_id = NEW.user_id，就会读到该用户本不该看到的已发货订单 - 使用
mysql.sys或自定义函数时，只要定义者有权限，触发器就能拿到系统变量、进程列表甚至文件内容 - 触发器无法感知列级权限（COLUMN_PRIVILEGES），对被屏蔽的列仍可读写（只要表级权限允许）
生产环境启用触发器前必须做的三件事
不是加个触发器就完事，尤其在权限模型复杂或接入了 ProxySQL / MaxScale 的场景下：
- 显式声明
SQL SECURITY INVOKER，除非业务逻辑确实需要定义者权限（如统一写审计日志到中心库） - 禁用
log_bin_trust_function_creators = OFF（默认值），防止用户创建带副作用的函数再被触发器调用；如必须启用，只给可信账号SUPER权限 - 所有触发器必须走 DDL 变更流程审核：检查
ACTION_STATEMENT是否含子查询、临时表、外部函数；确认没有循环触发（如 A 表触发器改 B 表，B 表触发器又改 A 表）
最常被忽略的一点：触发器错误不会中断主 DML 语句（除非是 BEFORE 触发器抛出异常），但错误日志只写在 MySQL 错误日志里，且默认不记录具体哪条语句触发了它——这意味着权限越界行为可能长期静默发生。
