大表查询慢的核心在于数据库未走最优执行路径，需通过合理建索引、规范SQL写法、更新统计信息、善用分区及深度分析执行计划来优化。
大表查询慢，核心问题不在数据多，而在数据库没走对路——索引没建对、条件没写准、统计信息过期、执行计划走了全表扫描。优化不是堆硬件，而是让SQL和引擎“彼此理解”。
索引不是越多越好，而是要匹配查询模式
建索引前先看WHERE、JOIN、ORDER BY、GROUP BY里真正用到的字段。单列索引对等值查询有效，但范围查询（>、INDEX (a, b, c)能加速 WHERE a = ? AND b > ?，但对 WHERE b = ? 无效。
- 高频查询条件字段优先建索引，尤其主键、外键、状态码、时间范围字段
- 避免在低区分度字段（如 gender、is_deleted）上单独建索引
- 用
EXPLAIN看key和rows，确认是否命中索引、预估扫描行数 - 定期用
ANALYZE TABLE更新统计信息，避免优化器误判
SQL写法直接影响执行路径
同一个业务逻辑，不同写法可能触发全表扫描或索引跳跃扫描。例如：SELECT * FROM orders WHERE DATE(create_time) = '2024-01-01' 会让索引失效，因为函数作用于字段；应改写为 create_time >= '2024-01-01' AND create_time 。
- 少用
SELECT *，只查需要字段，减少IO和网络传输 - 避免在WHERE中对字段做运算或函数处理（如
UPPER(name)、col + 1 = 10） - 分页慎用
LIMIT offset, size，深分页（offset > 10w）建议用游标分页（记录上一页最大ID） - 关联大表时，确保JOIN字段类型一致、都有索引，且小表驱动大表（MySQL中）
分区不是银弹，但适合特定场景
分区本质是把一张大表逻辑拆成多个子表，适用于按时间或ID范围高频筛选的场景（如日志表按月分区）。它不减少单次查询的数据量，但能裁剪掉不相关的分区，降低扫描范围。
- RANGE分区适合时间字段（如
PARTITION BY RANGE (TO_DAYS(create_time))） - LIST/KEY分区适合枚举类或哈希分布场景
- 注意：跨分区查询仍可能慢；全局唯一索引受限；维护成本上升（如删旧分区）
- 先评估查询是否集中在某几个分区，再决定是否分区
执行计划是诊断的第一现场
EXPLAIN FORMAT=TRADITIONAL 或 EXPLAIN ANALYZE（MySQL 8.0.18+）能真实展示执行过程。重点关注：type（是否用到索引，ALL最差，const/eq_ref最好）、key（实际使用的索引）、rows（预估扫描行数）、Extra（是否Using filesort、Using temporary、Using index等）。
- 看到
type: ALL就说明没走索引，优先排查WHERE条件或索引设计 -
Using filesort表示排序未走索引，可考虑为ORDER BY字段加联合索引 -
Using temporary多出现在GROUP BY或DISTINCT无合适索引时，尝试覆盖索引优化 - 对比前后执行计划变化，比单纯看响应时间更能定位瓶颈
基本上就这些。优化大表没有一招鲜，关键是养成“查执行计划→看索引覆盖→审SQL写法→验数据分布”的闭环习惯。不复杂，但容易忽略。
