大表查询慢的核心在于数据量级瓶颈，优化需聚焦数据分布、访问模式与执行引擎协作。关键思路包括：合理设计复合索引顺序、避免索引列运算、先过滤再JOIN、分区与预计算聚合、读懂执行计划信号。
大表查询慢，核心问题往往不在SQL写得“错”，而在于没避开数据量级带来的天然瓶颈。优化不是堆索引、不是换写法，而是理解数据分布、访问模式和执行引擎如何协作。下面用几个真实场景拆解关键思路。
索引不是越多越好，要匹配查询条件+排序+分页的组合拳
常见误区：给WHERE字段加了索引，但查询还走全表扫描。原因常是复合条件顺序不匹配、用了函数或类型隐式转换，或者分页偏移量过大（如 LIMIT 100000,20）。
- WHERE a = ? AND b > ? ORDER BY c DESC LIMIT 20 → 最佳索引是 (a, b, c)，注意顺序：等值条件在前，范围+排序字段依次靠后
- 避免在索引列上做运算：WHERE YEAR(create_time) = 2024 → 改成 create_time >= '2024-01-01' AND create_time 2025-01-01'
- 深分页卡顿？改用游标分页：记录上一页最后一条的主键值，下一页查 WHERE id > ? ORDER BY id LIMIT 20
别让JOIN把大表拖垮，先筛再连是铁律
大表A（5000万行）JOIN大表B（3000万行），即使有索引，中间结果集也可能爆炸。关键不是“能不能JOIN”，而是“要不要现在JOIN”。
- 先用子查询或CTE把A缩小到几千行（比如加时间范围+状态过滤），再跟B关联
- 确认JOIN字段类型严格一致（int vs bigint、varchar(255) vs varchar(50)都可能拒绝走索引）
- 业务允许时，把高频JOIN结果冗余到主表（如订单表存用户昵称），用空间换单表查询速度
聚合统计别硬扫，预计算+分区是稳解
每天跑 SELECT COUNT(*) FROM order WHERE dt = '2024-06-01' AND status = 1 —— 表超千万后，这种查询会越来越慢。
- 按天/月对大表做RANGE或LIST分区，让引擎自动裁剪数据文件
- 建汇总表：每小时跑一次 INSERT INTO order_daily_summary SELECT dt, status, COUNT(*) FROM order WHERE dt = ? GROUP BY dt, status
- 用物化视图（MySQL 8.0+支持表达式索引，PostgreSQL支持真正物化视图）缓存聚合结果
执行计划不是摆设，要看懂Key、Rows、Extra里的潜台词
EXPLAIN结果里几个信号要立刻警觉：
- type=ALL：正在全表扫描，赶紧看WHERE有没有走索引
- key=NULL：明明建了索引却没用，检查是否用了函数、OR条件未规范、字符集不一致
- Extra: Using filesort / Using temporary：排序或分组没走索引，考虑调整ORDER BY字段顺序或加覆盖索引
- Rows远大于实际返回数：说明索引选择性差（比如性别字段建了索引），删掉它
基本上就这些。优化没有银弹，但每次慢查都值得拆开执行计划、画出数据流向、问一句“这里真的需要读这么多行吗”。查得少，自然快。
