不能“禁用函数调用”，只能通过权限管控（grant/revoke execute）、执行上下文（sql security invoker/definer）和环境隔离（从机配置、只读账户、secure_file_priv）三重机制实现安全控制。
直接结论：不能“禁用函数调用”，只能控制谁有权限调用、在哪能调用、以谁的身份执行
MySQL 没有全局开关一键禁用所有存储过程或函数。所谓“禁用”，本质是权限管控 + 执行上下文约束 + 环境隔离。强行删代码或堵语法（比如改源码）既不可靠也不支持升级，反而破坏兼容性。
GRANT/REVOKE EXECUTE 是唯一可靠且标准的控制入口
用户能否 CALL mydb.my_proc，只取决于他有没有被显式授予 EXECUTE ON PROCEDURE mydb.my_proc 权限。没这个权限，哪怕他有 SELECT、INSERT 全库权限，CALL 也会立刻报错：ERROR 1370 (42000): execute command denied to user。
- 必须精确到
数据库名.存储过程名，mydb.*对存储过程无效 -
GRANT EXECUTE ON PROCEDURE mydb.p_safe TO 'app'@'10.20.%'—— 只放行一个过程 -
REVOKE EXECUTE ON PROCEDURE mydb.p_dangerous FROM 'dev'@'%'—— 立即切断调用链 - 不执行
FLUSH PRIVILEGES：常规GRANT/REVOKE语句自动生效，仅修改系统表后才需手动刷新
SQL SECURITY INVOKER 是防越权的关键设置
过程里查表、删数据，到底用谁的权限？默认 SQL SECURITY DEFINER（创建者权限），极易导致隐式提权——比如 DBA 创建的过程，普通用户一调就查了敏感表。真正可控的做法是声明 SQL SECURITY INVOKER：
CREATE PROCEDURE get_user_orders() SQL SECURITY INVOKER BEGIN SELECT * FROM orders WHERE user_id = USER(); END;
这样过程内所有 SQL 都校验调用者自身权限，哪怕过程存在，用户没 SELECT 权限也查不了 orders 表。
- 不写
SQL SECURITY时，MySQL 5.7+ 默认为DEFINER，但定义者账号若被删或权限变更，过程会直接失效 -
INVOKER不等于“更安全”——它只是把权限检查逻辑显式暴露出来，方便审计和收敛 - 过程里调用其他过程或函数时，同样受各自
SQL SECURITY设置约束，不会穿透
从机、只读账户、secure_file_priv 是三道隔离防线
不是所有环境都需要运行业务过程。对从机、报表用户、外部接入账号，应叠加物理或逻辑隔离：
- 从机配置
replicate-ignore-db = mysql：避免复制系统库里的过程，也防止意外执行 - 只读账户不授
EXECUTE，哪怕过程存在，CALL也过不去权限检查 -
secure_file_priv = ''或指定目录：让LOAD_FILE()、SELECT ... INTO OUTFILE失效，阻断文件级危险路径 - 别在
mysql库建业务过程——普通用户默认无权调用，且该库权限模型特殊，易出错
真正难处理的从来不是“怎么禁”，而是“谁该有、在哪用、以谁身份跑”。权限粒度、执行上下文、部署拓扑这三点漏掉任何一环，所谓“禁用”都只是假象。
