如何使用MySQL快速定位慢SQL问题？

        在企业级开发中，尤其是涉及到订单查询的业务时，经常会发生慢查询的问题。比如用户翻页到后面的页数时，查询变慢，因为传统的LIMIT offset, size在数据量大时效率低下。这时候，需要分析执行计划，看看是否全表扫描，或者索引使用情况。可能的问题是没有使用覆盖索引，或者offset过大导致扫描大量数据。
        在定位和优化慢查询问题的时候，首先需要开启慢查询日志。然后，设置合适的阈值，比如超过2秒的查询记录下来。接着，通过日志分析工具，比如mysqldumpslow（Percona的pt-query-digest也可以），来找出最耗时的查询。接下来，优化方法可能需要使用延迟关联，或者基于游标的分页，比如记录上一页的最大ID，这样避免使用大的offset。同时，添加合适的索引，比如在查询条件和排序字段上建立复合索引，可能覆盖查询所需字段，减少回表操作。

        另外，为了以后避免类似问题再次发生，在实际开发中的代码审查时要注意分页写法。

下面，我们举几个实际企业级开发中经常遇到的慢查询的例子，展开来详细分析并给出合理的慢查询优化建议。希望通过这两个例子，将慢查询的分析排查以及优化的过程做一个详细的分析，让大家都能有一个清晰的理解，方便以后大家在企业级开发中遇到类似问题能够游刃有余。

———————(●'◡'●)—————————华丽的分割线—————————————————

示例二：（第一个例子在上一篇博文中，这是第二个例子。）

场景背景

某订单管理平台订单列表页出现性能问题：当用户查询历史订单（特别是翻页到100页之后）时，页面响应时间超过5秒，收到用户反馈对该问题进行定位和优化。

• 订单表结构（实际企业级开发中的订单表结构远比一下列出的更加复杂，再次为了方便举例和理解，做了简化）：

  CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    user_id INT NOT NULL,
    order_status TINYINT,
    create_time DATETIME,
    total_amount DECIMAL(10,2),
    INDEX idx_user (user_id)
  );

---

第一阶段：问题定位

1. 启用慢查询日志

-- 动态开启（生产环境慎用）
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2; -- 捕获超过2秒的查询
SET GLOBAL log_queries_not_using_indexes = 'ON'; -- 记录未走索引的查询

2. 分析工具(这里使用的是mysqldumpslow，如果想进行更加深度的分析，可以使用Percona Toolkit)

# 分析最耗时的前10个慢查询
mysqldumpslow -s t -t 10 /var/lib/mysql/slow.log

# 分析特定模式的查询（如包含SELECT的语句）
mysqldumpslow -g "SELECT" /var/lib/mysql/slow.log

3. 分析工具输出解析

Count: 128  Time=3.24s (414s)  Lock=0.00s (0s)  Rows=20.0 (2560)
  SELECT id, user_id, order_status, create_time, total_amount 
  FROM orders 
  WHERE user_id = N 
  ORDER BY create_time DESC 
  LIMIT N, N

输出关键指标解读：

• Count: 该模式查询发生的总次数（128次）

• Time: 平均执行时间3.24s，总耗时414秒

• Rows: 平均返回20行，总计2560行

• 暴露高频慢SQL模式：带大偏移量的分页查询

---

第二阶段：问题分析

1. 执行计划分析

EXPLAIN SELECT ... -- 显示type=range, key=idx_user, rows=10240

通过查看EXPLAIN的输出，重点关注以下指标：

• type：查询类型，值越靠前（如const、ref）表示性能越好，ALL表示全表扫描，性能最差

• possible_keys和key：显示可能使用的索引和实际使用的索引，若key为NULL，说明没有使用索引。

• rows：查询需要扫描的行数，数值越大表示性能越差。

• Extra：包含额外信息，如Using filesort表示需要额外排序操作，Using temporary表示需要创建临时表。

分析：

• 虽然使用了user_id索引，但需要回表获取所有字段

• LIMIT 10000,20导致扫描前10020行再丢弃前10000行

2. 性能瓶颈点

• 索引覆盖不全：idx_user仅包含user_id

• 分页深度过大时产生大量无效IO

• 排序字段与索引顺序不一致导致filesort

---

第三阶段：确定优化方案

方案1：延迟关联优化

SELECT o.* 
FROM orders o
JOIN (
    SELECT id
    FROM orders
    WHERE user_id = 123
    ORDER BY create_time DESC
    LIMIT 10000, 20
) AS tmp USING(id);

• 子查询使用覆盖索引快速定位主键

• 外层查询通过主键快速获取完整数据

方案2：索引优化

ALTER TABLE orders 
ADD INDEX idx_user_create_time(user_id, create_time DESC);

• 覆盖查询条件和排序字段：将(user_id, create_time DESC)作为联合索引

• 避免filesort和随机IO

方案3：游标分页优化：优化limit

记录上一页最后一条记录的create_time：

SELECT * 
FROM orders 
WHERE user_id = 123 
  AND create_time < '2023-08-20 14:30:00' 
ORDER BY create_time DESC 
LIMIT 20;

---

第四阶段：效果验证

优化后执行计划显示：

• type=ref

• key=idx_user_create_time

• Extra=Using index

压测结果对比：

指标	优化前	优化后
查询时间(10000 offset)	4.8s	32ms
IO次数	10240	20
锁等待时间	220ms	0ms

---

如何避免类型情况再次发生？

1. 预防

• 代码审查时禁止直接使用LIMIT offset
• 分页深度超过100时强制转为游标分页

    2.监控：

-- 使用performance_schema实时监控
SELECT * 
FROM performance_schema.events_statements_summary_by_digest 
ORDER BY sum_timer_wait DESC 
LIMIT 10;

---

经验总结

1. 分页查询超过1000行偏移量必须优化

2. 组合索引字段顺序遵循WHERE→ORDER BY→SELECT原则

3. OLTP系统单表数据量超过500万需考虑分库分表