英语翻译网站开发快速整站优化
如何使用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.log3. 分析工具输出解析
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 idFROM ordersWHERE user_id = 123ORDER BY create_time DESCLIMIT 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 |
如何避免类型情况再次发生？
-
预防
- 代码审查时禁止直接使用
LIMIT offset - 分页深度超过100时强制转为游标分页
2.监控：
-- 使用performance_schema实时监控
SELECT *
FROM performance_schema.events_statements_summary_by_digest
ORDER BY sum_timer_wait DESC
LIMIT 10;经验总结
-
分页查询超过1000行偏移量必须优化
-
组合索引字段顺序遵循
WHERE→ORDER BY→SELECT原则 -
OLTP系统单表数据量超过500万需考虑分库分表