必须显式授予grant execute on procedure db.proc_name，因mysql不支持数据库级通配授权；过程内sql执行边界由sql security invoker/definer决定，execute权限与查看定义（需alter routine）分离。
只能执行特定存储过程，靠 GRANT EXECUTE ON PROCEDURE 就够了，但必须精确到「库名.过程名」，不能用通配符，也不能靠给数据库级权限“捎带”。
为什么 GRANT EXECUTE ON mydb.* 对存储过程无效
MySQL 的 EXECUTE 权限不支持数据库级通配授权。写成 GRANT EXECUTE ON mydb.* TO 'u'@'%' 会被 MySQL 忽略——它只认具体过程名。常见错误是误以为和 SELECT 权限一样能批量授权，结果 CALL 仍报 ERROR 1370 (42000): execute command denied。
必须显式指定：
GRANT EXECUTE ON PROCEDURE mydb.proc_a TO 'u'@'%'GRANT EXECUTE ON PROCEDURE mydb.proc_b TO 'u'@'%'
如果过程在 mysql 系统库下，普通用户默认无权调用，也不建议把业务过程放那里。
SQL SECURITY INVOKER 是限制执行边界的真正开关
光有 EXECUTE 权限还不够：过程内部的 SQL（比如 SELECT FROM orders）是否能跑通，取决于 SQL SECURITY 设置。默认是 DEFINER，意味着过程以创建者身份查表——这等于变相提权。
要真正限制用户“只能做过程允许的事”，必须声明：
CREATE PROCEDURE mydb.get_user_summary() SQL SECURITY INVOKER BEGIN SELECT id, name FROM users WHERE status = 'active'; END
这样，即使过程存在，只要调用者没 SELECT 权限，执行时就会直接报错，不会绕过。
不声明时 MySQL 5.7+ 默认为 DEFINER，但若定义者账号被删或权限回收，过程会突然失效。
用户能调用，但看不到源码？这是权限分离的正常表现
很多 DBA 以为“能 CALL 就该能 SHOW CREATE PROCEDURE”，其实不是。EXECUTE 和查看定义是两套权限：
-
EXECUTE→ 允许调用 -
ALTER ROUTINE→ 允许查看、修改、删除定义（注意：这个权限实际包含删除能力，慎授）
所以，只给 EXECUTE 的用户执行 SHOW CREATE PROCEDURE mydb.proc_a 会报 ERROR 1370 (42000): alter routine command denied。这不是 bug，是设计如此。
如果真需要开放查看权限，且不想给修改/删除能力，MySQL 8.0+ 可考虑通过视图 INFORMATION_SCHEMA.ROUTINES 配合行级过滤间接实现，但原生不支持“只读定义”粒度。
动态授权类过程必须用 SQL SECURITY DEFINER + 高权限 DEFINER
如果过程里要执行 GRANT 或 REVOKE（比如封装权限分配逻辑），不能直接写，必须用 PREPARE + EXECUTE 动态 SQL，并确保：
- 过程显式声明
SQL SECURITY DEFINER -
DEFINER是真实存在的高权限账户（如'dba'@'%'），且拥有GRANT OPTION - 不能设为
CURRENT_USER，也不能省略DEFINER字段
否则会报 ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s) 或更隐蔽的静默失败（比如目标用户不存在时 GRANT 不报错也不生效）。
最易被忽略的一点：EXECUTE 是独立权限，不随 SELECT/INSERT 自动附带；而过程内 SQL 的执行边界，只取决于 SQL SECURITY 设置，跟谁写的无关。
