EXECUTE权限仅控制调用存储过程或函数的权限，不涉及底层表读写；其生效需精确到数据库和过程名，且依赖DEFINER权限模型。
MySQL 中 EXECUTE 权限到底管什么
EXECUTE 权限只控制「能否调用」存储过程或函数，不涉及对底层表的读写——哪怕用户对过程里访问的所有表都没任何权限，只要被授予了 EXECUTE，就能成功执行（前提是过程以 DEFINER 方式创建且定义者有足够权限）。这是最容易混淆的一点：很多人以为给了 EXECUTE 就等于放行了数据访问，其实不是。
常见错误现象：ERROR 1370 (42000): execute command denied to user，但查了 SHOW GRANTS 又发现明明有 EXECUTE，结果发现是权限没刷到具体数据库+过程名层级，或者用了通配符却忽略了 schema 限定。
- 权限必须指定到具体数据库和过程名，例如
GRANT EXECUTE ON PROCEDURE mydb.my_proc TO 'user'@'%'；GRANT EXECUTE ON *.*不生效 - 如果过程在
mysql系统库，普通用户默认无法获得其 EXECUTE 权限（权限表本身受保护） - 使用
DEFINER = 'admin'@'localhost'创建的过程，执行时会以 admin 身份检查底层表权限，而非调用者身份
如何正确授予存储过程执行权限（含跨库场景）
MySQL 的 EXECUTE 授权粒度很细，必须显式声明数据库名和过程名，不能靠模糊匹配或继承。跨库调用时尤其容易漏掉权限配置。
使用场景：A 库有个过程 sync_data，需要让 B 库的用户能调用它；或者一个 DBA 用户要为多个业务库批量授权。
- 单个过程：执行
GRANT EXECUTE ON PROCEDURE app_db.sync_task TO 'worker'@'10.0.1.%' - 整个数据库下所有过程/函数：用
GRANT EXECUTE ON app_db.* TO 'worker'@'10.0.1.%'（注意不是app_db.%） - 跨库调用时，如果过程内部用到了
other_db.table，调用者不需要对other_db有权限——只要DEFINER有即可 - 授完权后必须执行
FLUSH PRIVILEGES，否则部分 MySQL 版本（尤其是 5.7 之前）不会立即生效
为什么 SHOW GRANTS 看不到 EXECUTE 权限
这是 MySQL 权限系统的一个隐蔽行为：当 EXECUTE 权限是通过 ON db_name.* 或 ON *.* 授予时，SHOW GRANTS 默认不显示它，除非你明确查该用户的全局或库级权限细节。
常见错误现象：执行了 GRANT EXECUTE ON mydb.* TO 'u'@'%'，再运行 SHOW GRANTS FOR 'u'@'%' 却看不到 EXECUTE 字样，误以为失败。
- 验证是否真正生效，用
SELECT * FROM mysql.procs_priv WHERE User='u' AND Db='mydb'（需有SELECT权限查系统表） - 更可靠的方式是直接测试调用：
CALL mydb.test_proc()，看是否报错ERROR 1370 - MySQL 8.0+ 支持
SHOW GRANTS FOR 'u'@'%' USING 'role_name'，但 EXECUTE 仍不会出现在基础SHOW GRANTS输出里
存储过程权限与 DEFINER/INVOKER 模式的实际影响
EXECUTE 权限只是“钥匙”，而 DEFINER/INVOKER 才决定这把钥匙打开门后能干什么。忽略这个区别，轻则过程执行失败，重则产生越权访问。
性能与兼容性提示：MySQL 5.7 默认用 DEFINER，8.0 开始支持 SQL SECURITY INVOKER，但后者要求调用者对过程中所有对象都有对应权限，实际部署中极少启用。
- 用
CREATE PROCEDURE p() SQL SECURITY DEFINER ...是默认行为，安全模型依赖定义者权限 - 改用
INVOKER后，即使给了EXECUTE，调用时仍可能报ERROR 1142: SELECT command denied，因为检查的是调用者权限 - 过程重建（
DROP + CREATE）后，DEFINER会重置为当前用户，可能导致原定行为失效——务必显式写明DEFINER='admin'@'localhost'
权限体系里最麻烦的从来不是“怎么加”，而是“加在哪一层”和“以谁的身份执行”。DEFINER 是个黑盒，EXECUTE 是个开关，两者不对照着看，很容易在上线后才发现数据查不出来或者日志里一堆权限错误。
