触发器无SQL SECURITY选项，强制以DEFINER身份执行；DEFINER必须是mysql.user中真实存在的用户（含精确host），且需具备触发器内所有SQL所需的最小权限，不可事后修改，只能删重建。
触发器没有SQL SECURITY选项，DEFINER是唯一权限控制点
MySQL 触发器不支持 SQL SECURITY INVOKER —— 它压根没有这个语法。所有触发器都强制以 DEFINER 身份执行，且无法在创建后修改。这意味着：触发器体内的每条 SQL（比如 INSERT INTO audit_log）都会用 DEFINER 的权限去校验，调用者权限完全不参与判断。
常见错误现象：Access denied for user 'app_user'@'%' to table 'sys.audit_log'，但触发器里写的明明是 INSERT INTO app_db.audit_log？问题往往出在 DEFINER='root'@'localhost'，而应用连接是远程的，'root'@'localhost' 在远程会话中不可用，导致权限回退失败。
-
DEFINER必须是mysql.user表中真实存在的账户（含精确的 host 部分），否则触发器创建会成功，但首次触发就报错 - 创建时若省略
DEFINER，MySQL 默认设为CURRENT_USER()，迁移环境时极易因用户缺失或 host 不符失效 - 触发器对权限的“透支”能力极强：只要
DEFINER有写权限，哪怕调用者只有INSERT表权限，也能在触发器里偷偷查、删、跨库操作
如何安全指定触发器的DEFINER账户
必须显式声明 DEFINER，且该账户需具备触发器内所有 SQL 涉及的最小权限集。例如一个记录变更日志的 BEFORE UPDATE 触发器：
CREATE DEFINER='trigger_admin'@'%' TRIGGER log_user_update
BEFORE UPDATE ON users
FOR EACH ROW
INSERT INTO audit_log(table_name, op, old_email, new_email, changed_by)
VALUES ('users', 'UPDATE', OLD.email, NEW.email, USER());
这里 trigger_admin 至少要拥有：
-
INSERT权限 onaudit_log表 -
SELECT权限 onusers表（OLD/NEW引用需要） - 如果
audit_log在另一库，还得有对应库的INSERT权限
注意：USER() 返回调用者身份，可用于日志记录；但 CURRENT_USER() 返回的是 DEFINER，别混淆。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
为什么不能靠“改DEFINER”来临时降权
MySQL 不提供 ALTER TRIGGER ... DEFINER=... 语法（8.0.16+ 的 ALTER PROCEDURE 支持也不适用于触发器）。想换 DEFINER，只能删掉重建：
- 先用
SHOW CREATE TRIGGER log_user_update拿到完整定义 - 手动替换开头的
DEFINER='old'@'host'为目标账户，比如DEFINER='audit_writer'@'%' - 确保新
DEFINER已被授予触发器内所有操作所需的权限（漏一条就会触发失败） - 执行
DROP TRIGGER log_user_update再CREATE新版本
重建过程必须在事务外进行，且期间无并发 DML，否则可能丢失变更事件。
DEFINER权限失控的真实风险场景
最危险的情况不是权限不够，而是权限太宽：
- 用
root或admin做DEFINER，结果触发器里写了DELETE FROM mysql.user—— 任何能触发它的普通用户都能间接删账号 - 触发器调用存储过程，而该过程又是
SQL SECURITY DEFINER，形成双重权限叠加，调用链越长越难审计 - 误将
DEFINER='dev'@'localhost'用于生产，上线后因 host 不符，触发器静默失效，审计日志断档
真正可控的做法是：为每个触发器创建专用低权限账户（如 trigger_orders_writer），只授其触发逻辑所必需的单表单操作权限，并禁用登录能力（ACCOUNT LOCK）。
