SQL优化实战：从执行计划到索引设计

1. 为什么SQL优化是每个开发者的必修课

上周排查一个生产环境问题时，发现某个报表查询竟然要跑8分钟。查看执行计划才发现是全表扫描了2000万条记录，加上错误的连接顺序导致性能雪崩。这让我想起刚入行时踩过的坑——很多开发者把SQL当作黑盒子，只关心结果不管过程。实际上，SQL优化是性价比最高的性能提升手段，往往一个索引就能让查询从分钟级降到毫秒级。

今天我们就用真实案例，拆解从执行计划解读到索引设计的完整优化路径。无论你是刚接触数据库的新手，还是想系统提升优化能力的老手，这套方法都能直接套用到你的项目中。我们会用MySQL 8.0演示，但原理通用所有关系型数据库。

2. 执行计划：SQL优化的X光片

2.1 EXPLAIN命令深度解读

拿到慢查询后，第一件事就是用EXPLAIN看执行计划。这个命令会展示MySQL如何执行你的SQL，就像给查询做CT扫描。关键要关注这几个字段：

sql复制EXPLAIN FORMAT=JSON 
SELECT * FROM orders o 
JOIN users u ON o.user_id = u.id
WHERE u.status = 'active' 
AND o.create_time > '2023-01-01';

输出中的access_type字段特别重要：

• ALL：全表扫描（红色警报）
• index：全索引扫描
• range：索引范围扫描
• ref/eq_ref：索引等值查询（理想状态）

最近帮客户优化过一个典型案例：某电商平台的订单搜索接口超时。EXPLAIN显示对order_item表进行了ALL扫描，仅这一步就处理了1200万行数据。

2.2 执行计划中的性能杀手

这几个信号出现时就要警惕了：

1. Using filesort：说明排序没用上索引，需要临时表
2. Using temporary：创建了临时表处理结果集
3. Select tables optimized away：理想状态，直接从索引获取结果

去年优化过一个统计报表，就因为GROUP BY没走索引导致生成400MB临时表，把服务器内存撑爆。后来通过创建(category, date)的联合索引，执行时间从47秒降到0.8秒。

3. 索引设计的艺术与科学

3.1 B+树索引原理实战

所有建议"加索引"的文章都没告诉你：索引是把双刃剑。理解B+树原理才能用好它。比如你知道为什么推荐用自增主键吗？

因为B+树的叶子节点是双向链表，自增ID插入时只需追加，而UUID会导致频繁的分裂和页合并。我们做过压测：同样500万数据，UUID主键的写入TPS比自增ID低38%。

3.2 联合索引的最左前缀原则

这是最容易被误解的规则。假设有联合索引(a,b,c)：

sql复制WHERE a=1 AND b>2 AND c=3  -- 只能用a,b
WHERE b=2 AND c=3          -- 用不上索引
WHERE a=1 AND c=3          -- 只用a

曾见过同事创建了(user_id, status)索引，但查询只用status条件，结果索引完全失效。正确的做法是把高频查询字段放在左边。

3.3 索引选择性：少即是多

选择性=不重复值/总行数。给性别这种低选择性字段加索引通常没用。有个经验公式：

code复制选择性 > 0.2 适合建索引
选择性 < 0.1 不建议建

但要注意特例：某物流系统用(province, city)做联合索引，虽然province只有30多个值，但加上city后选择性骤增，查询速度提升20倍。

4. 高级优化技巧实录

4.1 分页查询的终极方案

LIMIT 10000, 10这种深分页为什么慢？因为它要先读取10010条再抛弃前10000条。我们优化过的一个案例：

sql复制-- 原始写法（执行2.4秒）
SELECT * FROM articles 
WHERE user_id=123 
ORDER BY id DESC 
LIMIT 100000, 20;

-- 优化方案（0.01秒）
SELECT * FROM articles 
WHERE user_id=123 AND id < last_seen_id 
ORDER BY id DESC 
LIMIT 20;

配合前端记录最后一条记录的ID，性能提升240倍。

4.2 连接查询优化三原则

1. 小表驱动大表：把结果集小的表作为驱动表
2. 索引覆盖：确保连接字段有索引
3. 避免子查询：多数情况JOIN性能更好

最近重构的一个复杂查询，通过调整JOIN顺序+索引覆盖，从11秒降到0.3秒。关键是把只有10条记录的维度表作为驱动表。

5. 实战避坑指南

5.1 索引失效的六大场景

1. 对索引列做运算：WHERE YEAR(create_time)=2023
2. 使用否定条件：!=, NOT IN
3. 隐式类型转换：user_id='123'（本是int）
4. LIKE左模糊：LIKE '%abc'
5. OR条件未全覆盖
6. 函数调用：WHERE SUBSTRING(name,1,3)='abc'

上周刚解决一个BUG：WHERE mobile=13800138000没走索引，因为mobile字段是varchar类型。

5.2 数据库配置的隐藏参数

这几个参数调整后性能立竿见影：

ini复制innodb_buffer_pool_size = 12G  # 建议设为内存的70%
innodb_io_capacity = 2000      # SSD建议2000+
innodb_stats_on_metadata = OFF  # 避免自动更新统计信息

某客户从默认配置优化后，TPS从800提升到3500。但要特别注意：修改配置后一定要用sysbench做基准测试。

6. 性能优化完整案例

去年优化的一个真实电商系统：

1. 现象：订单导出功能超时（>5分钟）
2. 分析：
   • EXPLAIN显示对orders表全表扫描
   • 存在WHERE create_time BETWEEN ? AND ?条件
   • 现有索引是(user_id, status)
3. 解决方案：
   • 新增(create_time, user_id)联合索引
   • 改写查询为分批处理
   • 使用FORCE INDEX确保走新索引
4. 结果：执行时间从312秒降到1.4秒

关键点在于理解业务场景——这个导出功能总是按时间范围筛选，但原有索引完全没考虑这个模式。

7. 工具链推荐

1. pt-index-usage：分析哪些索引从未被使用
2. sys schema：MySQL自带的性能视图
3. Percona PMM：监控数据库性能
4. SQLAdvisor：美团开源的索引推荐工具

最近用pt-index-usage发现某系统有23个冗余索引，删除后写入性能提升15%。但切记：删除前要确认这些索引确实不在生产查询中使用。