MySQL本身不记录存储过程被谁调用，无内置机制追踪CALL来源的应用、IP或代码位置；可行路径包括开启general_log、查应用日志与代码（含ORM配置）、分析SHOW PROCESSLIST瞬时快照及代理层日志。
MySQL 本身不记录存储过程被谁调用
MySQL 没有内置机制去追踪 CALL sp_name() 是从哪个应用、哪台服务器、哪个 IP 或哪段代码发起的。日志里不会自动记下“Java 应用 A 在 10:23:45 调用了 sp_order_calc”。这是最常被误以为存在但实际缺失的功能。
能查到的只有“谁在用”，靠人工+外部手段定位
真正可行的路径是组合排查，不是单条 SQL 能解决的：
-
查 MySQL general_log（如果开着）：它会记录所有语句，包括
CALL，但默认关闭；开启后 I/O 和磁盘压力明显，生产环境慎用；需提前配置general_log = ON和general_log_file -
查应用层日志：搜索项目代码里的
CALL、call、stored procedure、sp_等关键词；注意 ORM 框架（如 MyBatis 的<select statementtype="CALLABLE"></select>）或 JDBCCallableStatement调用点 -
查数据库连接来源：用
SHOW PROCESSLIST可看到当前活跃连接的Host和Info（含正在执行的CALL），但只是瞬时快照，无法回溯历史 - 代理层/中间件日志：如使用 ProxySQL、ShardingSphere 或自研网关，它们可能记录了完整调用链，包括客户端 IP、应用名、SQL 文本
代码搜索时要注意的匹配模式
单纯 grep CALL sp_xxx 很容易漏掉真实调用点：
- 字符串拼接场景：
"CALL " + procName、String.format("CALL %s", name)—— 需搜引号内带CALL或变量插值模式 - 配置驱动调用：YAML/properties 文件里定义
procedure.name=sp_inventory_check，代码中读取后拼接 —— 需同步搜配置文件 - MyBatis XML 中的
{call sp_update_status(?, ?)}写法，括号和空格易被忽略 —— 建议用正则\{call\s+sp_\w+ - Spring
@Procedure注解：@Procedure(name = "sp_user_report")—— 注解名和属性值都要覆盖
全文本检索建议用 ripgrep 或 ag，别只靠 grep -r
对大型 Java/Python 工程，rg "CALL|@Procedure|statementType.*CALLABLE" 比 grep -r 快且默认跳过二进制和 node_modules；关键点在于：
- 搜索范围必须包含
src/main/resources（SQL 脚本、MyBatis XML）、src/main/java（注解、JDBC 调用）、config/（配置项） - 注意大小写：MySQL 默认不区分大小写，但代码里
call和CALL都可能出现 - 排除干扰：加
--type-not=pdf --type-not=log避免扫描无意义文件
真正难的从来不是“怎么查”，而是“哪些地方可能藏了调用”——应用代码、定时任务脚本、运维手动执行记录、旧版已下线但未清理的模块，都得逐个过一遍。
