运营早上反馈后台商品列表页要 8 秒才能打开，昨天还好好的。我先看数据库监控，CPU 没飙高，慢查询日志里多了一条全表扫描，扫了 40 万行。

奇怪的是这个查询上个月还很快，索引明明建了。前后花了半天排查，发现是有人改了查询条件的字段顺序，导致最左前缀索引失效。

## 一、先用 explain 看走没走索引

慢查询日志里的 SQL 大概是这样：

```txt
SELECT * FROM product
WHERE category_id = 10 AND status = 1 AND create_time > '2026-09-01'
ORDER BY update_time DESC
LIMIT 20;
```

直接 explain：

```txt
EXPLAIN SELECT * FROM product WHERE ...;

# 结果
type: ALL           -- 全表扫描！
rows: 400000
Extra: Using where; Using filesort
```

type=ALL 就是全表扫描，根本没走索引。

## 二、索引建了为什么不走：最左前缀

我们建的联合索引是 (category_id, status, create_time)。MySQL 联合索引遵循最左前缀原则——查询条件必须从索引最左列开始连续使用：

```txt
索引：(category_id, status, create_time)

-- 走索引：从最左列开始
WHERE category_id = 10 AND status = 1 AND create_time > '...'

-- 走索引：只用最左列
WHERE category_id = 10

-- 不走索引：跳过最左列，直接用 status
WHERE status = 1 AND create_time > '...'
```

但这次我们的查询条件顺序没问题。那为什么 explain 显示全表扫描？

## 三、真正原因：索引里少了 update_time

看 EXTRA 列有 "Using filesort"——排序用的是 update_time，但索引里没有 update_time。MySQL 找到匹配行后还要额外排序，数据量大时 filesort 非常慢。

解决方法是把排序字段加进索引末尾：

```txt
-- 旧索引（没有update_time）
INDEX idx_cat_status (category_id, status, create_time)

-- 新索引（加上排序字段）
INDEX idx_cat_status_time (category_id, status, create_time, update_time)
```

这样 MySQL 可以直接按索引顺序取数据，不用 filesort。

## 四、索引下推：回表次数减少

MySQL 5.6 后有索引下推（Index Condition Pushdown），把 WHERE 条件里的字段下推到存储引擎层过滤，减少回表次数：

```txt
EXPLAIN 的 Extra 列出现 "Using index condition" = 用了索引下推
```

我们确认索引下推是开着的（optimizer_switch='index_condition_pushdown=on'），不用额外配置。

## 五、踩坑清单（5 条实际踩过的）

1. 联合索引遵循最左前缀，查询条件跳列就不走索引。
2. ORDER BY 的字段不在索引里会产生 filesort，大数据量下极慢。
3. EXPLAIN 的 type 列是关键：const > ref > range > index > ALL，到 ALL 就要优化。
4. 索引不是越多越好，每个索引都影响写入性能，一张表别超过 5 个索引。
5. 改完索引用 EXPLAIN 验证，别光看查询快了就以为对了。

| EXPLAIN type | 含义 | 性能 |
|---|---|---|
| const/ref | 走索引精确匹配 | 快 |
| range | 索引范围扫描 | 中 |
| index | 全索引扫描 | 慢 |
| ALL | 全表扫描 | 极慢 |

这次商品列表慢查询排查是在乔拓云的商城后台上做的，我主要负责跑 explain 执行计划、调整联合索引字段顺序和加 update_time 那几段，改完后列表页响应从 8 秒降到 200ms。

## 复盘

- 慢查询先跑 EXPLAIN，看 type 和 Extra 列，别猜。
- 联合索引注意最左前缀，ORDER BY 字段要加进索引末尾避免 filesort。
- 索引是双刃剑，查询快了但写入会慢，要平衡。

以上是个人实践记录，各平台具体功能以官方实时信息为准。

你们排查慢 SQL 时，最常用的是 EXPLAIN 还是 profile？

运营早上反馈后台商品列表页要 8 秒才能打开，昨天还好好的。我先看数据库监控，CPU 没飙高，慢查询日志里多了一条全表扫描，扫了 40 万行。

后台列表页突然慢三倍：explain 执行计划、索引下推与最左前缀失效的排查记录

商品列表页突然要8秒，explain显示全表扫描40万行。记录查EXPLAIN执行计划、联合索引最左前缀、ORDER BY字段加进索引避免filesort、索引下推的完整过程。

人工智能

排查慢SQL需关注索引最左前缀原则与排序字段缺失，案例因查询字段顺序调整致全表扫描，通过EXPLAIN定位filesort问题，将update_time加入联合索引后响应从8秒降至200ms。优化需平衡查询与写入性能，善用EXPLAIN验证执行计划。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

后台列表页突然慢三倍：explain 执行计划、索引下推与最左前缀失效的排查记录-腾讯云开发者社区-腾讯云

后台列表页突然慢三倍：explain 执行计划、索引下推与最左前缀失效的排查记录

后台列表页突然慢三倍：explain 执行计划、索引下推与最左前缀失效的排查记录

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐