query-optimization

name	query-optimization
description	查询优化指南 —— 慢查询分析、索引调优、执行计划解读与 N+1 问题治理
category	数据/性能
loading	on-demand
triggers	{"keywords":["查询优化","SQL优化","慢查询","索引优化","N+1","explain","执行计划"]}

查询优化指南

概述

提供数据库查询性能优化的系统化方法论，覆盖从慢查询定位、执行计划分析、索引设计到 ORM N+1 问题的全链路优化。

使用场景

• 线上数据库负载过高需要定位慢查询
• 接口响应时间异常需要排查 SQL 性能
• 索引设计评审和优化建议
• ORM 查询的 N+1 问题排查和修复

核心原则

1. 先测量再优化：没有执行计划（EXPLAIN）数据的优化是盲目的。永远基于指标而非直觉做决策。
2. 索引是最廉价的优化：在查询频繁且过滤性好的列上建立索引，收益远高于代码层面的优化。
3. 减少数据传输量：SELECT * 是性能杀手——只查需要的列；分页必须有合理的 LIMIT。
4. 避免循环查询（N+1）：ORM 懒加载是 N+1 的主要来源。使用 JOIN 或批量预加载（prefetch_related / eager loading）替代。
5. 覆盖索引最大化：如果索引包含查询所需的所有列，则无需回表查询，性能提升数倍。

常见优化手段

• 执行计划分析：关注 type（range > index > ALL）、rows（扫描行数）、Extra（Using filesort 是坏信号）
• 联合索引：遵循最左前缀原则，高选择性的列放左侧
• 分页优化：大 offset 用游标分页或 WHERE id > last_id LIMIT n 替代 OFFSET
• 查询重写：子查询改 JOIN、OR 改 UNION、避免函数操作索引列

检查清单

• 是否通过 EXPLAIN 分析了所有核心查询的执行计划？
• 是否存在未使用索引的全表扫描（type=ALL）？
• 是否存在 N+1 查询（ORM 循环加载关联数据）？
• 分页查询是否有合理的 LIMIT 和索引支持？
• 是否有慢查询日志的监控和告警机制？