如何使用慢查询日志分析MySQL存储过程-mysql教程-PHP中文网

慢查询日志只记录call语句而不展开存储过程内部sql，需通过rows_examined与rows_sent对比、单独explain过程内sql、确保参数类型与字段一致、避免裸select等手段定位和优化性能瓶颈。

如何使用慢查询日志分析mysql存储过程

慢查询日志里只记 CALL，不记内部 SQL

直接查 slow_query_log 文件，你只会看到类似 CALL proc_user_report(202608, 'active') 这样的记录，耗时 1.8s —— 但日志**完全不展开**过程体内的任何语句。这不是 bug，是设计如此：MySQL 把存储过程调用当作一条独立语句处理，内部执行逻辑不在日志上下文中暴露。

所以别指望靠 grep CALL 找出哪条 SELECT 拖垮了性能。真正要盯的是这条记录的 Rows_examined 值：如果它远大于 Rows_sent（比如 50 万 vs 10），基本说明过程里有全表扫描或低效 JOIN。

开启日志前先确认配置：SET GLOBAL slow_query_log = ON;、SET GLOBAL long_query_time = 0.5;
强烈建议同时开 SET GLOBAL log_queries_not_using_indexes = ON;——哪怕语句没超时，只要没走索引就记，这对定位存储过程内“安静却致命”的语句特别有用
日志路径用 SHOW VARIABLES LIKE 'slow_query_log_file'; 确认，确保 MySQL 用户对该路径有写权限

EXPLAIN 必须脱离存储过程单独跑

EXPLAIN CALL proc_name(...) 没有意义，它只分析调用动作本身，输出永远是 type: SIMPLE、key: NULL。真正要优化的，是过程体里那些 SELECT、UPDATE、INSERT ... SELECT 语句。

操作步骤很直接：打开过程定义（SHOW CREATE PROCEDURE proc_name;），把疑似慢的 SQL 拿出来，**手动代入真实参数值**再跑 EXPLAIN FORMAT=TREE。例如过程里有 WHERE user_id = p_user_id，就换成 WHERE user_id = 12345。

MySQL

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

下载

绝对不要用变量形式 WHERE id = @var 或 WHERE id = p_id 做 EXPLAIN——优化器无法估算选择率，rows 字段会严重失真
重点看三个字段：type（不是 ALL 或 index）、key（是否命中你建的索引）、rows（是否接近实际匹配行数）
如果 Extra 出现 Using temporary 或 Using filesort，说明 ORDER BY 或 GROUP BY 没走索引，得补复合索引

存储过程里裸 SELECT 是隐形炸弹

写 SELECT status, count FROM t_log WHERE day = p_day; 却没接 INTO @v_status, @v_count，MySQL 会强制构造完整结果集、分配网络缓冲区、触发协议层打包——哪怕你根本不需要返回数据。这在循环里尤其危险，每执行一次都放大内存和上下文开销。

所有中间查询必须明确归宿：

要取值 → 用 SELECT col INTO var_name
要写入临时表 → 用 INSERT INTO tmp SELECT ...
只判断存在性 → 改成 SELECT COUNT(*) > 0 + IF
调试用的 SELECT * 必须上线前删光，它们在高并发下会迅速吃光连接内存

参数类型不一致直接让索引失效

过程定义 IN p_user_id VARCHAR(32)，但表字段是 BIGINT，调用 CALL proc(123) 时，MySQL 会把字段隐式转成字符串再比对，索引立刻失效。同理，CHARSET 不同（如 utf8mb4 vs utf8）、函数包裹（WHERE DATE(created_at) = '2026-08-10'）也会断掉索引链。

检查方法很简单：把过程里那句 SQL 拿出来，用 EXPLAIN 看 key 是否为 NULL，再对比 SHOW CREATE TABLE 里的字段定义和过程参数声明。