不能。Performance Schema 不直接统计存储过程 QPS，events_statements_summary_by_digest 等表会将 CALL 拆解为内部语句而丢失上下文；需启用 statement/sql/call instrument 并查询 events_statements_history_long 中 EVENT_NAME = 'statement/sql/call' 的原始事件进行分钟级频次统计。
Performance Schema 能不能直接统计存储过程的 QPS？
不能。Performance Schema 本身不提供「存储过程每秒执行次数」的聚合指标，events_statements_summary_by_digest 或 events_statements_summary_by_program 表里也不会把 CALL proc_name() 单独归为一类统计项——它会按实际执行的内部语句（比如 SELECT/INSERT）拆解记录，丢失调用上下文。
怎么间接抓到 CALL 的执行频次？
必须启用 statement digest + 程序对象监控，并过滤出 CALL 类型事件：
- 确认已开启：
performance_schema= ON，且consumers中启用了events_statements_current和events_statements_history_long - 执行：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_current', 'events_statements_history_long'); - 确保
setup_instruments中启用了语句级采集：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'statement/sql/call%'; - 查询时用
EVENT_NAME = 'statement/sql/call'过滤，例如：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_history_long 而不是 summary 表？
events_statements_summary_by_digest 会把所有 CALL 合并成一条摘要（digest），无法区分不同存储过程；而 events_statements_history_long 保留原始事件，可结合 OBJECT_NAME 字段提取具体被调用的存储过程名：
SELECT OBJECT_NAME, COUNT(*) FROM performance_schema.events_statements_history_long WHERE EVENT_NAME = 'statement/sql/call' AND TIMER_START > ... GROUP BY OBJECT_NAME;- 注意：
OBJECT_NAME在 CALL 事件中才有效，其他语句类型为空 - 该表有容量限制（默认 10000 行），高频调用下可能被覆盖，不适合长期归档，仅适合分钟级盯屏或短时排查
真实生产环境要注意的三个硬限制
Performance Schema 对存储过程的监控不是开箱即用的“指标面板”，它更像一个带条件的探针：
- MySQL 5.7+ 才支持
statement/sql/callinstrument，5.6 及更早版本查不到任何 CALL 事件 - 开启后有明确性能开销：每个 CALL 语句多一次 instrumentation hook，QPS 超过 500 时建议压测验证延迟增幅
-
events_statements_history_long默认不持久化，服务重启即清空；若需留存，得配合定时导出脚本或外接日志轮转逻辑
真正要稳定监控存储过程调用量，得在应用层埋点或在代理层（如 ProxySQL、MyCat）拦截 CALL 流量——Performance Schema 只适合临时定位“哪个 proc 突然被狂刷”。
