怎样在MySQL中统计存储过程被调用的频率与耗时？-mysql教程-PHP中文网

mysql不提供存储过程qps直接统计，必须启用statement/sql/call instrument及events_statements_history_long consumer，再按event_name='statement/sql/call'过滤查询分钟级调用频次。

怎样在mysql中统计存储过程被调用的频率与耗时？

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 上（比如隐式临时表、未走索引的子查询、游标遍历大结果集）：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

先查摘要排序：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'。否则服务重启或连接池轮转后，监控又断了。