大表查询慢的本质是扫描、定位、计算耗时过多；优化核心是减少无效IO、加速定位、避免全表扫描，需合理建索引、用游标分页、防锁升级、预聚合统计、冷热分离。
大表查询慢，本质是数据库在扫描、定位、计算时花了太多时间。优化不是堆硬件，而是减少无效IO、加速数据定位、避开全表扫描。
索引不是越多越好，而是要匹配查询模式
索引的核心作用是把“找数据”从遍历变成跳查。但只有当WHERE、JOIN、ORDER BY、GROUP BY中用到的字段被合理覆盖，索引才生效。
- 单列索引适合等值查询（如 WHERE status = 1）；复合索引要注意最左前缀原则（INDEX (a,b,c) 可用于 WHERE a=1 AND b>10，但对 WHERE b=5 无效）
- 避免对高重复字段（如性别、状态码）建单独索引——选择性太低，优化器可能直接放弃使用
- 定期用 EXPLAIN 看执行计划，确认是否走了索引、有没有 Using filesort 或 Using temporary
分页深翻必须绕开 OFFSET
SELECT * FROM big_table ORDER BY id LIMIT 10000,20 这类语句，MySQL 仍需扫描前10000行。数据越往后，性能越断崖下跌。
- 改用游标分页：记录上一页最大id，下一页查 WHERE id > 12345 ORDER BY id LIMIT 20
- 对非主键排序场景，可建立“排序字段 + 主键”联合索引，保证索引覆盖排序+定位
- 超10万级偏移量的后台导出，考虑用异步任务+临时表预聚合，不走实时分页
大表写操作要防锁与日志膨胀
UPDATE/DELETE 没带有效条件，或 WHERE 条件无法命中索引，容易触发全表扫描+行锁升级为表锁，拖垮整个库。
- 所有批量修改必须加 WHERE 索引字段，并提前用 SELECT COUNT(*) 预估影响行数
- 大表删数据别用 DELETE FROM，改用分区表按月/按状态归档，或分批（每次 1k~5k 行）+ 休眠控制压力
- 检查 innodb_log_file_size 和 binlog_format，避免单事务写入过大日志导致刷盘卡顿
统计与聚合尽量不碰原始大表
SELECT COUNT(*), AVG(price) FROM sales_2024 WHERE region='CN' 这类查询，每次都要扫千万行，响应慢还抢资源。
- 高频统计需求，用汇总表（如按天/按品类预计算）+ 定时任务增量更新
- 近似统计可用 SHOW TABLE STATUS 的 Rows（误差可接受时），或采样查询（TABLESAMPLE，MySQL 8.0.22+ 支持）
- 冷热分离：把一年前历史数据迁到归档库，主库只留活跃数据，从源头减小单表体积
基本上就这些。优化大表没有银弹，关键是看懂执行路径、理解存储引擎行为、再针对性切断瓶颈点。不复杂，但容易忽略细节。
