SQL 大数据量查询优化实战

查询慢主因是未命中索引而非数据量大；where字段无索引将触发全表扫描，explain中type为all即警告；避免函数操作、合理使用order by+limit分页、join时小表驱动大表并确保连接字段类型一致且有索引。

WHERE 条件没走索引，查 100 万行像查 100 行一样慢

不是数据量大就一定慢，是查询没命中索引才真卡。mysql/postgresql 都会先看 WHERE 字段有没有可用索引，没有就全表扫描——哪怕你只想要 1 条。

• 用 EXPLAIN 看执行计划，重点盯 type 列：出现 ALL 就是全表扫，range 或 ref 才算走索引
• WHERE 里别对字段做函数操作，比如 WHERE YEAR(created_at) = 2024 会让索引失效；改成 WHERE created_at >= '2024-01-01' AND created_at
• 联合索引要注意最左前缀：建了 (user_id, status, created_at)，那 WHERE user_id = 123 AND status = 'active' 能用，但 WHERE status = 'active' 就用不上

select * 拉太多字段，网络和内存都扛不住

大数据量下，传输和序列化开销可能比 SQL 执行本身还重。尤其当字段含 TEXT、json 或长字符串时，一条记录几百 KB 很常见。

• 只查真正需要的字段，明确写出列名，别偷懒写 SELECT *
• 避免在 SELECT 里用子查询或函数（如 CONCAT(name, '-', id)），这些会在每行上重复计算
• 如果前端只需要 ID 和标题，后端却查了 20 个字段+3 个 JSON 字段，IO 和 GC 压力会直线上升

OFFSET 越大越慢，分页查到第 1000 页直接超时

LIMIT 10 OFFSET 10000 不是跳过前 1 万条再取 10 条，而是让数据库先找出前 10010 条，再丢掉前 10000 条——数据越往后，成本越高。

• 改用游标分页：WHERE id > 12345 ORDER BY id LIMIT 10，靠主键或时间戳做“断点续查”
• 如果必须用 OFFSET，确保 ORDER BY 字段有索引，且和 WHERE 条件能组合使用（比如 WHERE status = 'done' ORDER BY created_at）
• 超过 10 万级偏移量，基本该考虑归档旧数据或加缓存层了，硬扛不现实

JOIN 多张大表，执行计划崩了都不知道怎么救

三张百万级表一 JOIN，如果没控制好驱动表顺序和连接字段索引，很容易触发 using temporary; Using filesort，甚至爆内存。

• 用 EXPLAIN 看 rows 预估行数，如果某张表预估几十万，而它又是被驱动表，大概率出问题
• 小表驱动大表：把过滤后只剩几百行的表放 FROM，大表放 JOIN 右侧；MySQL 5.7+ 会自动优化，但别完全依赖
• ON 条件字段类型要严格一致，比如 int 对 VARCHAR 会导致隐式转换，索引失效

最常被忽略的一点：索引不是建了就生效，得看查询条件是否匹配它的结构和顺序；而 EXPLAIN 输出里的 key_len 和 Extra 字段，才是真正告诉你“到底用了索引哪几列”的证据。