SQL查询优化核心是精准干预：一要建匹配查询路径的联合索引（等值→范围→排序），二要最小化数据访问（避免SELECT *、用游标分页），三要看清执行计划（防隐式转换、更新统计信息）。
面对超大数据表，SQL查询从分钟级降到秒级，核心不在“加机器”，而在“精准干预”。关键看三点：索引是否击中真实查询路径、数据访问是否最小化、执行计划是否被误导。
索引不是建得越多越好，而是要匹配WHERE+ORDER BY+JOIN的实际组合
很多团队在大表上堆了十几个单列索引，但查询仍慢——因为实际SQL常带多条件过滤+排序，单列索引无法生效。例如：
-
低效写法： WHERE status = 'active' AND created_at > '2023-01-01' ORDER BY updated_at DESC，却只对
status或created_at单独建索引； -
优化做法： 建联合索引
(status, created_at, updated_at)，顺序按“等值过滤→范围过滤→排序字段”排列，让索引覆盖整个查询路径。
注意：LIKE '%abc' 不走索引，'abc%' 才可利用索引前缀；NULL 值在B+树中处理特殊，避免在索引列上大量存NULL。
别让SELECT * 拖垮I/O和网络传输
超大宽表（50+列）查全字段，即使命中索引，也要回表取大量冗余数据，磁盘I/O和序列化开销剧增。
- 只查真正需要的字段，尤其是避开TEXT/BLOB/JSON类型列；
- 用
COUNT(*)替代COUNT(某字段)（后者需判NULL）； - 分页场景慎用
LIMIT 1000000, 20，改用“游标分页”：记录上一页最后一条的id或updated_at，下次查WHERE id > xxx ORDER BY id LIMIT 20。
看清执行计划，警惕隐式转换和统计信息过期
EXPLAIN ANALYZE 是唯一真相来源。常见坑点：
-
类型不匹配： 字段是
VARCHAR(32)，但SQL里写成WHERE user_id = 123（整型），触发隐式转换，索引失效； -
统计信息陈旧： 表数据量突增10倍后未
ANALYZE TABLE，优化器误判行数，选错索引或走全表扫描； -
JOIN顺序反直觉： 小表驱动大表原则失效时，手动用
STRAIGHT_JOIN（MySQL）或 CTE + MATERIALIZE（PostgreSQL 12+）控制连接顺序。
冷热分离与分区不是银弹，但能切掉80%无效扫描
对时间维度强的超大表（如日志、订单），物理拆分比逻辑优化见效更快：
- 按月/周做 RANGE分区（如
PARTITION BY RANGE (TO_DAYS(created_at))），查询带时间条件时自动Pruning； - 将3个月前的历史数据归档到
xxx_archive表，主表只留热数据，配合应用层路由； - 高频聚合场景，提前物化结果到汇总表（如每小时UV、订单金额），用定时任务刷新，查汇总表代替实时COUNT/SUM。
基本上就这些。不复杂，但容易忽略细节。
