当前位置：首页 > news >正文

蓝易云：MySQL之优化SELECT语句

news 2026/5/12 15:41:32

蓝易云：MySQL 之优化 SELECT 语句（把“慢”拆成可控的成本）⚡️

优化 SELECT 的本质是做三件事：让优化器选到更好的执行计划、让存储引擎少读数据页、让返回路径少做无效工作。你可以把一次查询的成本粗略理解为：
[
\text{总成本} \approx \text{扫描行数} \times \text{每行代价} + \text{排序/分组代价} + \text{回表代价}
]
目标就是把扫描行数、回表次数、排序/临时表这三块压下去。🙂

1）先定位：用 EXPLAIN 把“猜测”变“证据”🔍

EXPLAIN SELECT id, user_id, amount FROM orders WHERE user_id = 10086 AND status = 1 ORDER BY created_at DESC LIMIT 20;

解释（逐行抓重点）

EXPLAIN：不跑结果，只输出执行计划，用来判断有没有走到你期望的索引。
SELECT id, user_id, amount：只取必要字段，减少 IO 与网络传输；避免SELECT *导致多余列读取。
WHERE user_id = ... AND status = ...：等值过滤是索引最喜欢的形态。
ORDER BY created_at DESC LIMIT 20：如果能用同一个索引顺序返回，就能避免额外排序；否则容易出现“额外排序/临时表”的信号。

2）索引：让查询“走对路”，并尽量做到覆盖索引 ✅

ALTER TABLE orders ADD INDEX idx_user_status_ct (user_id, status, created_at, id);

解释

ALTER TABLE ... ADD INDEX：创建索引是优化 SELECT 的最高杠杆之一。
idx_user_status_ct (user_id, status, created_at, id)：
- user_id, status放前面：对应WHERE的高频过滤列，让扫描范围迅速收窄。
- created_at接着：配合ORDER BY created_at，有机会直接“按索引顺序”取前 20 条，减少排序。
- id放末尾：常用于让索引更容易覆盖查询或减少回表（是否需要取决于查询返回列）。
核心目标：让查询尽量变成Index Range Scan + 少回表，甚至直接覆盖索引（返回字段都在索引里）。

3）WHERE 写法：别让索引“失明”👀

-- 反例：对列做函数运算，容易导致索引失效 SELECT * FROM orders WHERE DATE(created_at) = '2026-03-04'; -- 正例：改成范围查询 SELECT * FROM orders WHERE created_at >= '2026-03-04 00:00:00' AND created_at < '2026-03-05 00:00:00';

解释

反例DATE(created_at)：把列先计算再比较，索引通常无法按原值做范围定位，扫描量会膨胀。
正例用时间范围：让created_at能参与索引范围扫描，扫描行数显著下降。
同类坑还有：隐式类型转换（字符串比数字）、前导通配符LIKE '%abc'、OR混合多列导致难以用单一索引。

4）分页：用“定位翻页”替代 OFFSET 大跳跃 🚀

-- 慢：OFFSET 越大越慢（MySQL 需要跳过前 N 行） SELECT id, created_at FROM orders WHERE user_id = 10086 ORDER BY created_at DESC LIMIT 20 OFFSET 200000; -- 快：基于“上一页最后一条”的定位翻页（Seek Method） SELECT id, created_at FROM orders WHERE user_id = 10086 AND created_at < '2026-03-04 12:00:00' ORDER BY created_at DESC LIMIT 20;

解释

OFFSET 200000：本质是“读出来再丢掉”，越翻越慢。
定位翻页：把上一页末尾的created_at（或(created_at,id)）当游标，直接从索引位置继续扫，成本稳定。
若存在相同时间戳，建议用created_at+id作为复合游标，避免漏/重复。

5）高频慢点与对策：一张表对齐思路📌

症状	典型原因	直接打法
扫描行数巨大	索引缺失 / 条件不可用索引	补联合索引；把函数/隐式转换改成范围或等值
排序很慢	`ORDER BY`无法用索引顺序	把排序列纳入联合索引并匹配顺序；减少排序字段
回表太多	只用到二级索引但要取很多列	做覆盖索引；只取必要列
JOIN 慢	驱动表不对/条件不走索引	小表驱动大表；`ON/WHERE`列补索引；只 JOIN 必要字段
分组慢	临时表/文件排序	用索引前缀分组；减少 group by 列；先过滤再聚合

6）优化落地工作流（团队协作更顺）🧠

flowchart TD A[抓慢SQL样本] --> B[EXPLAIN验证计划] B --> C{扫描行数高?} C -->|是| D[补索引/改WHERE写法] C -->|否| E{排序/临时表高?} E -->|是| F[调整ORDER BY/GROUP BY与索引顺序] E -->|否| G{回表多?} G -->|是| H[覆盖索引/减少返回列] G -->|否| I[验证收益与回归测试] I --> J[上线监控与复盘]