普通用户无法调用mysql存储过程的根本原因是execute权限未显式授予或definer失效、sql security配置不匹配；必须用grant execute on procedure精确授权，检查definer存在性及权限，按sql security模式确认调用者或definer具备过程内所有操作权限。
普通用户无法调用 MySQL 存储过程，**根本原因不是“没给权限”，而是 EXECUTE 权限压根没被显式授予，或者虽授了但 DEFINER 失效、SQL SECURITY 配置不匹配**。
GRANT EXECUTE ON PROCEDURE 必须写全关键字
很多人以为给了 SELECT 或 USAGE 就能调用存储过程，结果 CALL my_proc() 直接报 ERROR 1370 (42000): execute command denied。这是因为：
-
EXECUTE是独立权限，和SELECT、INSERT等完全不互通 - 授权语句必须带
PROCEDURE关键字，漏掉就无效：GRANT EXECUTE ON mydb.my_proc TO 'u'@'%'❌（实际授的是数据库级权限） - 正确写法只有一种：
GRANT EXECUTE ON PROCEDURE mydb.my_proc TO 'u'@'%'✅ - 注意反引号：如果库名或过程名含短横线、大小写或特殊字符，必须用
`my-db`.`my_proc`
SHOW CREATE PROCEDURE 查出 DEFINER 不存在或失效
即使 GRANT EXECUTE 成功，调用仍失败，大概率是存储过程定义里的 DEFINER 用户出了问题：
- 执行
SHOW CREATE PROCEDURE my_proc，看输出里是否有类似DEFINER=`old_admin`@`192.168.1.%` - 这个用户在当前实例上可能已被删、密码过期、账号锁定，或 host 不匹配（
'old_admin'@'localhost'≠'old_admin'@'%'） - 查用户是否存在：
SELECT User, Host FROM mysql.user WHERE User = 'old_admin' - 查其权限是否覆盖过程内所有操作：
SHOW GRANTS FOR 'old_admin'@'192.168.1.%' - 云数据库（如阿里云 RDS）严禁直接改
mysql.proc，必须导出→替换DEFINER→删除→重建
SQL SECURITY DEFINER 导致权限校验对象错位
默认 SQL SECURITY DEFINER 意味着：运行时检查的是 DEFINER 用户的权限，而不是调用者。这带来两个隐性陷阱：
- 过程里查了
other_db.t，但DEFINER没有SELECT ON other_db.t→ 调用失败 - 过程用了动态 SQL（如
CONCAT拼接表名），而DEFINER没有对应表的权限 → 同样崩 - 改成
SQL SECURITY INVOKER后，调用者必须自己拥有过程内所有表的SELECT/INSERT等权限，否则第一步就卡住 - 别指望
FLUSH PRIVILEGES能救活已失效的DEFINER——它只刷新权限缓存，不复活账号
调用者权限足够，但过程内部跨库访问被拦
这是最常被忽略的一环：你有 EXECUTE 权限，不代表过程能跑通。过程内部的 SQL 语句，仍受 MySQL 权限系统逐条校验：
- 若过程里执行
INSERT INTO audit.log，调用者（或DEFINER，取决于SQL SECURITY）必须有INSERT ON audit.log - 哪怕只读，
SELECT FROM billing.invoice也需要对应SELECT权限，不能靠“同库”自动继承 - 查看过程依赖的所有对象：
SELECT * FROM information_schema.routines WHERE routine_name = 'my_proc'，再人工核对每张表的权限链 - 特别注意视图、函数、其他存储过程——它们也有自己的
DEFINER和SQL SECURITY，一环断，全链崩
真正卡住普通用户的，从来不是语法或版本，而是权限链条里某一处没对齐：GRANT 少写了 PROCEDURE、DEFINER 用户 host 写成了 % 却只开了 localhost、SQL SECURITY 切换后忘了补调用者的跨库权限。这些点都得一个个抠，缺一不可。
