MySQL不提供存储过程QPS直接统计，必须启用statement/sql/call instrument及events_statements_history_long consumer，再按EVENT_NAME='statement/sql/call'过滤查询分钟级调用频次。
MySQL 不提供直接的“存储过程调用次数”或“QPS”聚合指标，information_schema.routines 里没有调用计数，SHOW STATUS LIKE 'proc_name' 是伪指令、实际无效；真正能用的只有 Performance Schema，但必须配对启用关键 instrument 和 consumer，否则查出来全是空。
查 CALL 语句的分钟级调用频次
Performance Schema 默认不把 CALL proc_name() 当作独立事件统计——它会拆解成内部 SQL，导致上下文丢失。必须显式启用 statement/sql/call 类型采集：
- 确认已开启：
SELECT @@performance_schema返回 1 - 启用采集器：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_current', 'events_statements_history_long') - 启用仪器：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME = 'statement/sql/call' - 查询最近 1 分钟调用次数：
SELECT COUNT(*) AS call_count, FROM_UNIXTIME(LEFT(TIMER_START, 10)) AS minute_ts FROM performance_schema.events_statements_history_long WHERE EVENT_NAME = 'statement/sql/call' AND TIMER_START > UNIX_TIMESTAMP(NOW() - INTERVAL 60 SECOND) * 1000000000 GROUP BY minute_ts;
注意：events_statements_summary_by_digest 里的 DIGEST_TEXT LIKE 'CALL%' 只能看历史总耗时排序，无法区分不同过程、也无法做时间窗口聚合。
定位高耗时存储过程及其内部瓶颈
看到某条 CALL 耗时高，别急着优化过程体——90% 的真实开销在它执行的内部 SQL 上（比如隐式临时表、未走索引的子查询、游标遍历大结果集）：
- 先查摘要排序：
SELECT DIGEST_TEXT, SUM_TIMER_WAIT, COUNT_STAR FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE 'CALL%' ORDER BY SUM_TIMER_WAIT DESC LIMIT 5 - 拿
DIGEST去events_statements_history_long查具体线程 ID 和执行时间戳 - 用线程 ID 关联
performance_schema.threads，确认PROCESSLIST_USER和PROCESSLIST_DB，排除系统线程干扰 - 再查该线程下的 I/O 和内存分配：
SELECT * FROM sys.io_by_thread_by_bytes WHERE thread LIKE '%CALL%'或SELECT user, current_allocated FROM sys.memory_by_thread_by_current_bytes m JOIN sys.session s ON m.thread_id = s.thd_id WHERE s.current_statement LIKE 'CALL%'
如果 sys 视图返回空，大概率是 memory/% instruments 没开：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'memory/%'。
为什么 sys.dm_exec_procedure_stats 不适用于 MySQL
这个视图属于 SQL Server，MySQL 里根本不存在。网上有些教程混用 MSSQL 和 MySQL 语法，一跑就报错 Unknown table 'sys.dm_exec_procedure_stats'。MySQL 中唯一可靠的路径就是 Performance Schema + events_statements_history_long，且必须手动打开所有依赖项，缺一不可。
最容易被忽略的是：所有 instrument 启用操作只对新连接生效，已有连接不会自动继承；若想长期有效，得在 my.cnf 里写死配置，比如 performance_schema_instrument = 'statement/sql/call=ON'。否则服务重启或连接池轮转后，监控又断了。
