大表查询优化核心是减少扫描行数、加快定位速度、降低返回数据量；需先分析SQL、表结构和数据分布，再针对性建组合索引、避免索引失效、优化分页与统计、实施冷热分离及分区归档。
大表查询慢，核心就三件事：减少扫描行数、加快定位速度、降低返回数据量。别一上来就加索引或换数据库，先看SQL干了啥、表结构咋样、数据分布如何。
索引不是万能的，但没索引一定很慢
对WHERE、JOIN、ORDER BY、GROUP BY中出现的字段，优先建索引。但要注意：单列索引不如组合索引高效，顺序很重要——把区分度高、过滤性强的列放前面。
- 比如查询red">SELECT * FROM orders WHERE status = 'paid' AND created_at > '2024-01-01'，status只有几个值（'draft','paid','shipped'），created_at时间范围窄，那(created_at, status)比(status, created_at)更有效
- 避免在索引列上用函数或计算：WHERE DATE(created_at) = '2024-01-01'会让索引失效，改成created_at >= '2024-01-01' AND created_at
- 用EXPLAIN看执行计划，重点盯type（最好为ref/const）、rows（越小越好）、key（是否命中索引）、Extra（避免Using filesort / Using temporary）
分页深翻？别用OFFSET，改用游标或条件偏移
当LIMIT 10000, 20变慢，不是因为取20条，而是MySQL仍要扫描前10000行。尤其在高并发场景下，这会成为性能瓶颈。
- 推荐用“上次最后ID”做游标分页：WHERE id > 12345 ORDER BY id LIMIT 20，配合id主键索引，毫秒级响应
- 如果排序字段非主键（比如按updated_at），可建(updated_at, id)联合索引，确保排序+去重稳定
- 真需要跳转到第N页？考虑前端缓存页码映射，或后台异步预生成分页摘要表
大表统计不准？别COUNT(*)，用近似或聚合表
对亿级订单表执行SELECT COUNT(*) FROM orders WHERE status = 'paid'，可能扫几千万行。业务真需要精确到个位数吗？
- 允许误差：MySQL 8.0+ 可查information_schema.INNODB_TABLESTATS估算行数；PostgreSQL 用pg_class.reltuples
- 高频精确统计：单独建轻量聚合表，如orders_daily_stats，每天凌晨跑一次汇总，查询走秒级响应
- 实时性要求高？用Redis HyperLogLog做去重计数，或ClickHouse做实时OLAP聚合
历史数据太多？冷热分离是性价比最高的方案
不是所有数据都要放在主表里扛着查询压力。把3年前的订单归档到orders_archive，主表只留最近12个月，效果立竿见影。
- 用PARTITION BY RANGE (created_at)按月分区（MySQL 8.0+/PostgreSQL），查询带时间条件时自动裁剪分区
- 归档不用DELETE——太慢还锁表。改用INSERT INTO ... SELECT + DROP PARTITION / RENAME TABLE原子操作
- 应用层路由：读请求按时间判断走主表还是归档库；写请求统一进主表，后台定时归档
基本上就这些。优化不是一步到位，而是从慢SQL出发，结合explain、监控、业务语义，一层层剥开问题。不复杂但容易忽略——比如一个没走索引的JOIN，就能让大表查询从200ms拖到8秒。
