调用存储过程需显式授予EXECUTE权限而非SUPER权限，且须注意SQL SECURITY DEFINER导致的权限校验对象变更及底层表权限缺失问题。
因为 SUPER 权限只解决“能不能执行高危系统操作”，不解决“能不能调用存储过程”——这两件事在 MySQL 权限体系里压根不是一回事。
GRANT EXECUTE ON PROCEDURE 才是调用存储过程的唯一门票
用户有 SUPER 权限，但执行 CALL proc_name() 仍报 ERROR 1370 (42000)，说明权限没给到点上。MySQL 不会把 SUPER 当作 EXECUTE 的替代品。
-
GRANT SUPER ON *.* TO 'u'@'h'允许用户改全局变量、杀连接、启停复制，但对调用某个具体存储过程毫无帮助 - 真正生效的只有一条：
GRANT EXECUTE ON PROCEDURE db_name.proc_name TO 'u'@'h'，PROCEDURE关键字不能省，db_name.proc_name必须写全名 -
SHOW GRANTS FOR 'u'@'h'输出里看不到GRANT EXECUTE ON PROCEDURE `db_name`.`proc_name`这一行，就等于没授权成功
SQL SECURITY DEFINER 会让 SUPER 权限“失效”
即使 EXECUTE 授权成功，调用仍失败，大概率是存储过程定义里写了 SQL SECURITY DEFINER（MySQL 默认行为）。这时权限校验对象变成创建者（DEFINER），而不是当前用户。
- 用
SHOW CREATE PROCEDURE proc_name查定义，确认是否含SQL SECURITY DEFINER - 如果 DEFINER 用户已被删，或其对某张底层表的
SELECT权限被回收，哪怕调用者有SUPER也无济于事 - 临时修复：重建过程，显式加上
SQL SECURITY INVOKER；长期建议避免硬编码 DEFINER
导入 SQL 脚本时提示需要 SUPER，通常和存储过程执行无关
报 ERROR 1227 或 ERROR 1419，往往是因为 SQL 文件里带了 DEFINER 子句、GTID_PURGED、SET GLOBAL 等语句，而不是因为你要调过程。
- 云数据库（如阿里云 RDS）默认禁用
SUPER，但照样能正常执行已存在的存储过程——只要EXECUTE权限到位 - 更安全的做法是预处理 SQL 文件：用
sed或awk删除/*!50013 DEFINER=... */和SET @@SESSION.GTID_PURGED相关行 - 盲目授
SUPER不仅治标不治本，还会让审计直接标红
真正卡住调用的，从来不是 SUPER 给没给，而是 EXECUTE 授没授到具体过程、SQL SECURITY 设没设对、以及过程内部访问的表权限调用者有没有——这三处漏掉任何一处，SUPER 都只是摆设。
