大数据量表的查询慢，核心问题往往不在SQL写法本身，而在于索引是否匹配查询模式、数据分布是否合理、以及执行计划是否被正确引导。优化不是堆索引，而是让索引真正“被用上”且“高效覆盖”。
精准匹配查询条件建索引
索引不是越多越好，关键看WHERE、JOIN、ORDER BY中实际出现的字段组合。单列索引对多条件查询效果有限，应优先考虑复合索引，并遵循最左前缀原则。
- 例如查询常写成 WHERE status = 'done' AND create_time > '2024-01-01' ORDER BY update_time DESC，适合建 (status, create_time, update_time) 复合索引
- 把高区分度字段（如 status）放前面，能更快过滤；范围查询字段（如 create_time）尽量靠后，避免阻断索引下推
- 避免在索引字段上做函数操作，比如 WHERE DATE(create_time) = '2024-01-01' 会让索引失效，改用 create_time >= '2024-01-01' AND create_time
覆盖索引减少回表开销
当查询只涉及索引包含的字段时，数据库可直接从索引页返回结果，无需再回主键索引查整行数据——这对IO密集型大表尤为关键。
- 例如表有 id、user_id、status、content、create_time 字段，但常用查询是 SELECT user_id, status, create_time FROM t WHERE status = 'pending'，可建索引 (status, user_id, create_time)
- 注意：不要盲目把所有SELECT字段都加进索引，尤其含 TEXT/BLOB 或长字符串字段会显著增大索引体积
- 用 EXPLAIN 检查 Extra 列是否出现 Using index，确认走的是覆盖扫描
分区+索引协同降低扫描量
单表超千万甚至上亿行时，即使有索引，全索引扫描仍可能很慢。按时间或业务维度分区（如按月分表或使用 RANGE/LIST 分区），能让查询自动裁剪到少数分区，再配合分区本地索引，效率跃升。
- 日志类、订单类表适合按 create_time 做 RANGE 分区，每月一个分区；查询最近7天数据时，仅访问2–3个分区
- 分区键最好与查询条件强相关，否则无法生效；同时确保每个分区内的数据量相对均衡
- MySQL 8.0+ 支持 ALTER TABLE ... REORGANIZE PARTITION 动态管理，避免手动拆分表
定期维护索引统计与碎片
数据持续写入会导致索引页分裂、统计信息过期，使优化器误判成本，选错执行计划。尤其在批量导入或高频更新后，必须干预。
- 执行 ANALYZE TABLE t 更新索引基数和数据分布统计，帮优化器更准估算行数
- InnoDB 表长期增删后可用 OPTIMIZE TABLE t（本质是重建表+索引），释放碎片空间；但注意该操作会锁表，建议在低峰期进行
- 监控 information_schema.INNODB_METRICS 中的 index_page_splits 和 index_page_reorgs，异常升高提示索引设计或写入模式需调整
不复杂但容易忽略。索引优化的本质是让数据组织方式贴合查询路径，而不是追求“全覆盖”或“全加速”。每次加索引前，先看慢查询日志里真实执行的语句和 EXPLAIN 结果，再动手。
