MySQL存储过程权限由EXECUTE权限控制，需显式授予“数据库.存储过程名”粒度权限；查看定义需额外ALTER ROUTINE权限；过程内表操作权限取决于SQL SECURITY设置（INVOKER更安全）。
MySQL 存储过程权限控制靠什么
存储过程本身不自带“调用开关”，它的执行权限完全由 MySQL 的 EXECUTE 权限控制。没这个权限，用户连 CALL 都会报错：ERROR 1370 (42000): execute command denied to user。权限粒度可以精确到「数据库.存储过程名」，不是只能开全局开关。
怎么给指定用户授予特定存储过程的 EXECUTE 权限
必须显式授权，不能靠创建者自动继承。常见错误是只给了 SELECT 或 USAGE，结果 CALL 仍失败。
GRANT EXECUTE ON PROCEDURE mydb.my_proc TO 'app_user'@'10.20.30.%';- 如果用户已存在，授权后需执行
FLUSH PRIVILEGES;（仅在直接操作 mysql 系统表后才强制需要；常规GRANT语句通常自动生效） - 注意：
mydb.my_proc中的数据库名不能用通配符，mydb.*不适用于存储过程授权 - 若过程在
mysql系统库下，普通用户默认无权调用，也不建议把业务过程放那里
为什么 SHOW CREATE PROCEDURE 也受权限限制
用户即使有 EXECUTE 权限，也不代表能看过程定义——这需要额外的 ALTER ROUTINE 权限。生产环境常有人误以为“能调用就能查源码”，结果 SHOW CREATE PROCEDURE 报 ERROR 1370 (42000): alter routine command denied。
- 仅需允许调用？只给
EXECUTE即可 - 还需允许查看或修改？再加
GRANT ALTER ROUTINE ON PROCEDURE mydb.my_proc TO ... -
ALTER ROUTINE权限实际包含查看、修改、删除过程的能力，慎授
存储过程内访问表时的权限检查时机
权限检查分两层：调用者是否有 EXECUTE 权限，以及过程内部 SQL 所涉表是否对**调用者**可见。过程不会以定义者身份“越权”查数据。
- 默认行为是
SQL SECURITY DEFINER（创建者权限），但前提是创建者自己有对应表权限，且你显式声明了它 - 更安全的做法是用
SQL SECURITY INVOKER—— 这样过程内所有表操作都校验调用者的权限，避免隐式提权 - 建过程时务必写明：
CREATE PROCEDURE my_proc() SQL SECURITY INVOKER BEGIN ... END - 不声明时 MySQL 5.7+ 默认为
DEFINER，但若定义者账号被删或权限变更，过程可能突然失效
EXECUTE 是独立权限，不随 SELECT/INSERT 等数据权限自动附带；而过程内 SQL 的执行边界，取决于 SQL SECURITY 设置，不是看谁写的过程。 
