DEFINER 权限由创建存储过程时指定的账户使用，执行时临时切换至该账户上下文；INVOKER 则全程校验调用者权限，体现最小权限原则；安全切换 DEFINER 需重建过程并精确授权。
DEFINER 权限到底是谁在用？
DEFINER 指的是创建存储过程时指定的账户，不是调用者。MySQL 执行时会 临时切换到该账户权限上下文 去执行过程体里的 SQL —— 即便调用者只有 EXECUTE 权限，也能间接读写 DEFINER 有权限的表。
常见错误现象：Access denied for user 'app_user'@'%' to database 'sys'，但过程里只查了 app_db.users？很可能 DEFINER 被设成了 'root'@'localhost'，而 root 在远程连接下无法匹配（host 不符），导致权限回退失败。
使用场景：
- 需要统一后台管理权限（如定时清理日志），但前端用户权限极低
- 多租户系统中，用
DEFINER隔离底层 schema 访问路径
注意点：
-
DEFINER必须是真实存在的、具有对应权限的账户 - 创建时若未显式指定，MySQL 默认用当前登录用户，容易在迁移或复现环境时出错
-
DEFINER的 host 部分必须精确匹配，'admin'@'%'和'admin'@'localhost'是两个完全不同的主体
INVOKER 权限怎么才真正生效？
SQL SECURITY INVOKER 表示全程使用调用者的权限校验。每条语句执行前，MySQL 都会检查当前连接用户是否对涉及对象有对应权限 —— 这才是“最小权限原则”的落地方式。
常见错误现象：过程能创建成功，但一调用就报 Table 'app_db.audit_log' doesn't exist，其实表存在，只是调用者没被授过 SELECT 权限；或者报 INSERT command denied，因为调用者只有 SELECT，没 INSERT。
参数差异：
- 创建时必须显式写
SQL SECURITY INVOKER，默认是DEFINER -
INVOKER下，CREATE PROCEDURE本身不检查调用者是否有目标表权限，只在校验调用时刻才检查
性能 / 兼容性影响：
- 几乎无性能差异，权限检查开销可忽略
- MySQL 5.0+ 全支持，但旧版客户端工具可能不显示
SQL SECURITY字段，容易误判
如何安全地切换 DEFINER 账户？
不能靠 ALTER PROCEDURE …… DEFINER=…… 直接改（MySQL 8.0.16+ 才支持，且需 SET_USER_ID 权限）。稳妥做法是重建：
- 先用
SHOW CREATE PROCEDURE proc_name拿到完整定义 - 把开头的
DEFINER=<code>old@host替换成新账户，比如DEFINER=<code>proc_admin@% - 确保新
DEFINER已被授予过程内所有 SQL 涉及的权限（包括库、表、列级权限） - 用
DROP PROCEDURE IF EXISTS proc_name+ 新CREATE语句重装
容易踩的坑：
- 忘记同步授权：改完
DEFINER后没给新账户授SELECT ON app_db.*，过程调用直接失败 - 使用通配符 host（如
'proc_admin'@'%'）但账户实际是从 localhost 连入，权限不匹配 - 在 RDS 或云数据库上，
root可能被限制为仅localhost，导致远程调用时DEFINER失效
调用者没权限，但又不想暴露 DEFINER 账户怎么办？
核心思路是：让 DEFINER 账户权限尽可能窄，只开过程内必需的最小集，再通过 GRANT EXECUTE 控制入口。
实操建议：
- 创建专用账户，如
'proc_runner'@'localhost'，只授过程涉及的几张表的SELECT/INSERT/UPDATE，不给DROP、CREATE、FILE等高危权限 - 过程内部避免动态拼接表名或库名（防止 SQL 注入绕过权限），优先用静态对象引用
- 若过程需访问多个库，别给
proc_runner全局权限，而是按需逐个GRANT - 审计时重点查
mysql.proc表里的definer和security_type字段，而不是只看调用者权限
权限模型本质是信任边界的划分：你信的是过程逻辑本身，还是调用它的那个人。多数业务场景下，INVOKER 更可控；但一旦过程封装了跨库聚合或敏感操作，DEFINER 就成了不得不设的隔离层——这时候，账户本身的权限粒度，比过程怎么写更关键。
