大表查询慢的本质是数据量过大而硬件资源有限，优化需围绕减少数据访问量、加速数据定位、降低计算开销三目标系统推进；索引须精准匹配查询模式，遵循最左前缀原则，高区分度字段靠左，善用覆盖索引与分区表，规避伪索引扫描、深分页及模糊查询陷阱，并以EXPLaiN验证执行计划。
大表查询慢，本质是数据库要扫描、过滤、排序的数据量太大，而硬件资源（CPU、内存、磁盘IO）有限。优化不是“加索引就完事”，而是围绕减少数据访问量、加速数据定位、降低计算开销三个核心目标系统性推进。
索引不是越多越好，而是要精准匹配查询模式
很多同学一遇到慢查就建索引，结果索引冗余、更新变慢、执行计划反而更差。关键看WHERE、JOIN、ORDER BY、GROUP BY中实际用到的字段组合和顺序。
- 联合索引要遵循“最左前缀”原则：比如INDEX (a, b, c)能加速
WHERE a=1 AND b=2，但对WHERE b=2无效 - 区分度高的字段尽量靠左：比如
status只有0/1两个值，放索引最左会大幅降低选择性 - 覆盖索引能避免回表：select只查索引字段时（如
SELECT id, name FROM user WHERE city='sh'，且有INDEX(city, id, name)），直接从索引取数，不查聚簇索引
避免全表扫描，但更要警惕“伪索引扫描”
EXPLAIN看到type=range或ref≠ALL，不代表真快。比如WHERE create_time > '2020-01-01'用了索引，但如果95%数据都满足条件，mysql仍可能放弃索引走全表——因为随机IO比顺序IO更贵。
- 用
SELECT count(*)验证筛选率：若返回行数 / 总行数 > 20%，索引收益可能很低 - 时间范围查询优先用分区表（按月/年分partition），把“大扫描”变成“小扫描”
- LIKE ‘%关键词%’无法用索引；
LIKE '前缀%'可以，但LIKE '%后缀'不行
分页深翻是性能杀手，必须换思路
OFFSET 100000 LIMIT 20看似简单，MySQL却要先扫出100020行再丢弃前10万——数据越往后，越慢。
- 用游标分页（cursor-based）：记录上一页最后一条的主键值，下一页查
WHERE id > 123456 LIMIT 20 - 业务允许时，前端限制最大翻页页码（如只允许到第200页）
- 高频深分页场景可预生成聚合视图或用elasticsearch做检索层
执行计划是唯一真相，别猜，要看
所有优化动作前，先跑EXPLAIN format=TRADITIONAL或EXPLAIN ANALYZE（MySQL 8.0.18+）。重点关注几项：
- type：system ≈ const > eq_ref > ref > range > index > ALL（ALL最危险）
- key：实际使用的索引名，NULL说明没走索引
- rows：预估扫描行数，远大于实际返回行数？说明索引失效或统计信息过期（可
ANALYZE table刷新） - Extra：出现using filesort、Using temporary、Using join buffer → 排序/分组/关联没走索引，需重点优化
基本上就这些。大表优化没有银弹，但抓住“减少、加速、降开销”这条主线，配合执行计划验证，90%的慢查都能定位根因。不复杂，但容易忽略细节。