大表查询慢的核心在于数据组织与访问路径不合理，需协同优化索引、分区、统计信息和执行计划。优先为高频查询条件建匹配的复合索引，避免低区分度字段单独建索引；合理使用覆盖索引减少回表；分区须满足查询能精准裁剪，推荐RANGE/LIST/HASH策略并配合局部索引；务必通过EXPLAIN验证分区裁剪与索引使用，定期更新统计信息，并借助慢日志定位瓶颈。
大表查询慢，核心问题往往不在SQL写法本身，而在数据组织方式和访问路径是否合理。索引、分区、统计信息、执行计划这四者协同作用，缺一不可。单靠加索引或盲目分区，反而可能适得其反。
索引不是越多越好，而是要匹配高频查询模式
对大表建索引前，先看WHERE条件字段、JOIN字段、ORDER BY/GROUP BY字段的组合规律。例如用户表按status和created_at联合过滤占80%流量，那就优先建复合索引(status, created_at)，而非单独为两个字段各建一个索引。
- 避免在低区分度字段（如性别、状态码）上单独建索引，效果微弱还拖慢写入
- 覆盖索引能减少回表：把SELECT中用到的非索引字段也加入索引末尾（如
INDEX (user_id, status) INCLUDE (name, email)，PostgreSQL/SQL Server支持；MySQL可用联合索引模拟） - 定期用
ANALYZE TABLE（MySQL）或ANALYZE（PG）更新统计信息，否则优化器可能选错索引
分区不是万能药，适用场景很明确
分区真正起效的前提是：查询能通过分区键精准裁剪掉大量分区。比如日志表按log_time范围分区，查“2024-05-01”的数据，只需扫描1个分区；但若查“所有ERROR级别日志”，而ERROR分散在所有分区里，性能反而更差。
- 常用分区策略：RANGE（时间类）、LIST（枚举类如地区编码）、HASH（均衡分布，适合等值查询但不支持范围裁剪）
- MySQL 5.7+ 支持
EXPLAIN PARTITIONS确认是否命中分区；PostgreSQL需结合EXPLAIN看是否出现Partition Filter - 注意分区维护成本：旧分区归档、新分区添加、全局索引失效等问题需配套脚本管理
组合策略：分区 + 局部索引，才是大表加速的常见解法
以订单表为例：order_date做RANGE分区（按月），每个分区内部再建(user_id, status)局部索引。这样既能按时间快速定位分区，又能在单个分区里高效查找用户订单——两层过滤叠加，比全局索引+全表扫描快几个数量级。
- 局部索引（每个分区独立索引）比全局索引更轻量，增删分区不影响其他分区索引
- 避免跨分区查询：如
SELECT * FROM orders WHERE user_id = 123没带时间条件，会扫描所有分区，此时应在应用层强制要求传入时间范围 - 测试时用
EXPLAIN逐层验证：是否走了分区裁剪？是否用了局部索引？是否发生了临时表或文件排序？
别忽略执行计划和慢日志这个“诊断听诊器”
90%的大表性能问题，都能从EXPLAIN输出里找到线索。重点关注type（访问类型）、rows（预估扫描行数）、Extra（是否Using filesort/Using temporary）三列。
- type=ALL 或 index 表示全表/全索引扫描，需立即优化；type=ref/range/const 才算走对路
- rows值远大于实际返回行数？说明统计信息过期或索引选择性差
- 开启慢查询日志（
long_query_time=1），用pt-query-digest或pg_stat_statements定位TOP消耗SQL，而不是凭感觉优化
基本上就这些。索引和分区都是工具，关键在理解数据特征和查询模式。不复杂但容易忽略——先看清执行计划，再动手建索引或分分区。
