MySQL默认不授予任何用户EXECUTE权限，即使已授SELECT或ALL PRIVILEGES；必须显式执行GRANT EXECUTE ON PROCEDURE db.proc_name TO 'u'@'h'或GRANT EXECUTE ON db.* TO 'u'@'h'，且需配合SQL SECURITY INVOKER及依赖对象最小权限控制。
CREATE USER 之后必须显式授予 EXECUTE 权限
MySQL 默认不给任何用户 EXECUTE 权限，哪怕你已经给了 SELECT 或 ALL PRIVILEGES，也不能调用存储过程。只创建用户、不授权 EXECUTE，执行 CALL proc_name() 会报错：ERROR 1370 (42000): execute command denied to user 'user'@'host' for routine 'db_name.proc_name'。
关键点在于：权限是按「对象粒度」控制的，EXECUTE 必须明确授予到具体存储过程（或整个数据库），不能靠“继承”获得。
- 授予单个存储过程：
GRANT EXECUTE ON PROCEDURE db_name.proc_name TO 'username'@'host'; - 授予整个数据库下所有存储过程：
GRANT EXECUTE ON db_name.* TO 'username'@'host'; - 不能写成
GRANT EXECUTE ON *.*—— 这只对函数/过程全局生效（需 SUPER 权限），且极不安全
SQL SECURITY 必须设为 INVOKER 才能限制数据访问范围
如果存储过程里有 SELECT * FROM users 这类语句，而用户本身没有 users 表的 SELECT 权限，那即使给了 EXECUTE，调用时仍会失败——除非该过程定义时用了 SQL SECURITY DEFINER（默认值），此时以定义者身份执行，绕过调用者权限检查。
但这就违背了“只允许执行特定过程”的初衷：用户可能通过过程间接读取本不该接触的数据。
- 创建时强制指定：
CREATE PROCEDURE get_my_orders(...) SQL SECURITY INVOKER BEGIN ... END; - 已有过程修改：
ALTER PROCEDURE proc_name SQL SECURITY INVOKER; -
INVOKER模式下，过程内每条 SQL 都受调用者当前权限约束，更可控
不要遗漏对过程依赖对象的最小权限
一个存储过程能否成功运行，不仅取决于 EXECUTE 权限，还取决于它内部访问的表、视图、函数是否对当前用户开放。比如过程里有 INSERT INTO log_table，用户就必须有 log_table 的 INSERT 权限；如果有 SELECT COUNT(*) FROM config，就得有 config 表的 SELECT 权限。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
常见踩坑点：开发测试时用 root 创建过程并设为 DEFINER，上线后切到受限用户，过程能调用但内部 SQL 报权限拒绝，错误信息往往不提示具体哪一行出问题。
- 先用目标用户连接，手动执行过程体内的 SQL 片段，验证权限是否到位
- 避免在过程里跨库操作（如
other_db.table），否则要额外授对应库的权限 - 若过程含动态 SQL（
PREPARE/EXECUTE），还需EXECUTE权限 + 对应对象的底层权限
生产环境务必禁用 '%' 主机通配符
为过程专用用户设置 'user'@'%' 是高危操作。攻击者一旦拿到该账号密码，就能从任意 IP 连接并调用过程——尤其当过程含敏感逻辑（如导出数据、触发清理）时风险极大。
应该严格限定来源：
- 应用服务器固定内网 IP：
'app_proc_user'@'192.168.5.12' - 容器或云环境用 CIDR：
'app_proc_user'@'10.20.0.%' - 本地运维临时用：
'dba_proc_user'@'localhost'
真正难把控的是过程内部的权限边界：INVOKER 模式下，权限校验发生在运行时，不是创建时。这意味着哪怕你反复检查了 SQL 语句，只要过程逻辑后续被修改（比如加了一行新查询），就可能悄悄突破原有权限设计。每次变更存储过程，都得重新走一遍调用者权限验证。
