SQL性能优化是系统性过程：先看执行计划识别瓶颈，再验证数据分布避免平均误导，然后按统计信息、索引、SQL逻辑、物理改造优先级调整，最后闭环验证真实效果。
SQL 性能优化不是靠堆索引、改写 SQL 或调参数来“碰运气”，而是从执行逻辑出发，层层定位瓶颈的系统性过程。核心是：先看执行计划，再看数据分布，最后才动 SQL 或结构。
第一步：读懂执行计划，识别真实瓶颈
执行计划（EXPLAIN 或执行计划图形）是 SQL 的“诊断报告”，不是装饰品。重点关注三类信息：
- 实际行数 vs 预估行数严重偏差：说明统计信息过期或查询条件选择率异常，优化器选错了路径；
- 高成本操作集中在哪：如全表扫描（Seq Scan）、嵌套循环（Nested Loop）驱动了大结果集、Hash Join 内存溢出到磁盘；
-
是否存在隐式类型转换或函数包裹字段：比如
WHERE TO_CHAR(create_time, 'YYYY-MM') = '2024-01'，会让索引失效。
第二步：验证数据特征，别被“平均”误导
很多慢查源于数据倾斜，而非 SQL 本身。例如：
- 某订单表按 user_id 关联，但 5% 的用户占了 80% 的订单量；
- 时间范围查询中，99% 的数据集中在最近 7 天，而 SQL 却扫了全分区；
- 字段基数低（如 status 只有 3 个值），建单列索引意义很小，反而可能拖慢写入。
建议用 SELECT COUNT(*), COUNT(DISTINCT col) FROM table 和直方图（如 PostgreSQL 的 pg_stats）快速判断分布。
第三步：按优先级调整，避免无效操作
优化动作要有明确依据和顺序：
-
先加/调统计信息：
ANALYZE table或设置更细粒度的采样（如ALTER TABLE t SET (STATISTICS=1000)）； - 再建精准索引：覆盖查询所需字段（INCLUDE）、匹配过滤+排序+连接顺序，避免冗余索引；
- 后改 SQL 逻辑：拆分复杂子查询、用 EXISTS 替代 IN（尤其右表大时）、避免 SELECT *；
- 最后才考虑物理改造：分区裁剪、物化视图、读写分离——这些解决的是架构级问题，不是单条 SQL 的病根。
第四步：验证闭环，关注真实效果
优化后必须在相同数据量、相似业务压力下对比：执行时间、逻辑读、CPU 时间、是否复用执行计划。仅看“快了 2 秒”可能掩盖内存抖动或锁竞争。生产环境建议用 A/B 测试方式灰度验证，避免误伤。
