大表查询慢的核心在于数据组织、访问路径和资源利用，需从设计、执行、监控三层面系统优化：合理建覆盖索引、避免索引失效、优化JOIN与分页、慎用统计查询、常态化监控治理。
大表查询慢，核心问题往往不在SQL写法本身，而在数据组织、访问路径和资源利用方式。优化不是堆硬件或改索引这么简单，得从设计、执行、监控三层面系统推进。
合理建索引：不求多，但求准
索引不是越多越好，重复、低选择性、长期不用的索引反而拖慢写入和维护。重点覆盖高频查询的 WHERE 条件字段 + ORDER BY 字段 + JOIN 关联字段，优先组合索引而非单列索引。比如查询常按 status = 'active' AND created_at > '2024-01-01' 过滤并按 updated_at DESC 排序，那就建 (status, created_at, updated_at) 覆盖索引。
- 用
EXPLAIN看是否命中索引、是否用到索引排序（Using filesort要警惕） - 避免在索引字段上做函数操作，如
WHERE YEAR(created_at) = 2024会让索引失效，改写为created_at >= '2024-01-01' AND created_at - 区分
SELECT *和只查必要字段，覆盖索引能避免回表，大幅提升速度
拆分与归档：让大表“变小”
单表千万级以上，光靠索引很难根治性能问题。物理上减负更有效：
-
水平分表：按时间（如按月分表
orders_202401）、ID取模或业务维度（如按用户ID哈希），配合路由逻辑或分区表（MySQL 8.0+ 支持 RANGE/LIST 分区） -
冷热分离：把一年前的历史订单移入
orders_history表，主表保持轻量；查询历史数据走专用通道 -
归档策略自动化：用定时任务 +
INSERT ... SELECT+DELETE分批归档，避免长事务锁表
查询重写与执行控制
很多慢查源于语义不清或数据库误判执行计划：
- 避免
SELECT * FROM big_table LIMIT 100000, 20这类深分页，改用游标分页：WHERE id > last_seen_id ORDER BY id LIMIT 20 - 关联大表时，确保驱动表（LEFT JOIN 左侧）是结果集最小的，必要时用
STRAIGHT_JOIN强制连接顺序 - 统计类查询（如 COUNT(*)）在超大表上慎用，可考虑冗余计数字段、近似统计（HyperLogLog）或异步汇总表
- 对临时结果集大的子查询，尝试改写为 JOIN 或物化为临时表（
CREATE TEMPORARY TABLE）
监控与持续治理
优化不是一锤子买卖。建立常态化机制才能守住成果：
- 开启慢查询日志（
long_query_time = 1），用pt-query-digest定期分析 Top SQL - 监控表的
Data_length / Index_length比值、碎片率（SHOW TABLE STATUS），定期OPTIMIZE TABLE（注意锁表影响） - 对高频更新的大表，评估是否启用
innodb_file_per_table=ON和innodb_page_cleaner参数调优 - 上线前必做执行计划对比，尤其关注
rows_examined是否异常增长
基本上就这些。真正有效的优化，是让数据库少干活、快定位、不瞎猜——设计阶段想清楚，上线后盯得住，问题来了下得去手。不复杂，但容易忽略。
