大表查询优化核心是减少扫描行数、避免全表扫描、合理建索引并控制结果集大小；需按最左前缀原则建联合索引，禁用深分页改用游标分页，拆分冷热数据，适度冗余预计算，并定期清理低效索引。
大表查询慢，核心问题往往不在sql写法本身，而在数据组织方式和访问路径是否合理。优化的关键是减少扫描行数、避免全表扫描、让查询尽可能走索引，并控制返回结果集大小。
加好索引，但别乱加
不是所有字段都适合建索引，也不是索引越多越好。重点给WHERE、JOIN、ORDER BY、GROUP BY中频繁出现的字段组合建索引。比如查询常按 status = 1 AND create_time > '2024-01-01' 过滤，就建联合索引 (status, create_time)，顺序不能颠倒。单列索引对多条件查询效果有限，而冗余索引（如已有 (a,b)，又单独建 a）会拖慢写入且浪费空间。
- 用
EXPLaiN看type是否为ref或range，避免ALL - 注意最左前缀原则：查询只用到
b字段时，(a,b)索引无法生效 - 字符串字段建索引要指定长度，如
INDEX idx_name (name(50))，避免索引过大
分页查询别用 OFFSET
当 LIMIT 1000000, 20 这类深分页出现时，mysql 仍需扫描前100万行才能跳过去，性能断崖式下跌。更优做法是用“游标分页”或“条件分页”：
- 记录上一页最后一条的主键值（如
id = 123456），下一页查WHERE id > 123456 ORDER BY id LIMIT 20 - 避免
select *，只查必要字段，尤其避开大文本（TEXT、BLOB）列 - 如果必须用 offset，考虑在应用层缓存中间偏移位置，或改用 elasticsearch 等专用检索引擎
拆分冷热数据，减少单表体量
历史数据（如一年前订单）查询频次低，却和热数据混在同一张表，拖慢整体查询。可按时间或业务维度归档：
- 用
ALTER table ... PARTITION BY RANGE (TO_DAYS(create_time))做分区，让查询自动裁剪分区 - 将旧数据迁出到历史表（如
order_2023），主表只保留近6个月数据 - 业务层路由：新订单写主表，查历史订单走归档表，配合视图或中间件统一接口
适当冗余和预计算
频繁聚合或关联查询慢，说明实时计算成本太高。可在写入时同步维护汇总结果：
- 用户订单总数不查
SELECT count(*) FROM orders WHERE uid=123，而是在用户表加order_count字段，下单后UPDATE users SET order_count = order_count + 1 WHERE id = 123 - 统计报表类需求，用定时任务（如每小时）把结果写入宽表，查询直接读这张轻量表
- 关联多张大表的场景，考虑生成物化视图（MySQL 8.0+ 可用汇总表模拟）或使用 clickhouse 做分析层
不复杂但容易忽略：定期用 SHOW INDEX FROM table_name 和 information_schema.STATISTICS 检查低效或未使用的索引，及时清理。优化不是一劳永逸，而是随数据增长和查询变化持续调整的过程。