大表查询慢的核心是减少数据扫描量和优化执行计划；需结合执行计划分析、精准建索引（等值>范围>排序）、更新统计信息、调优硬件与配置参数。
大表查询慢，核心就两件事：让数据库少扫描数据、让执行计划走对路。索引不是加了就快，SQL也不是重写就一定优——得看数据分布、查询条件、关联逻辑和执行计划反馈。
索引不是越多越好，而是要“打中查询的命门”
建索引前先看执行计划（EXPLAIN 或 EXPLAIN ANALYZE），确认是否走了全表扫描、是否用了索引但没生效。常见有效场景：
- WHERE 条件中的高选择性字段（如 user_id、order_no），优先建单列或组合索引，顺序按“等值 > 范围 > 排序/分组”排列（例如 WHERE status = ? AND create_time > ? ORDER BY id，适合建 (status, create_time, id)）
- JOIN 字段必须有索引，两边类型要严格一致（int vs bigint、varchar(50) vs varchar(100) 都可能让索引失效）
- 避免在索引字段上做函数操作（WHERE YEAR(create_time) = 2024 → 改成 create_time >= '2024-01-01' AND create_time 2025-01-01'）
- 覆盖索引能省掉回表：把 SELECT 中的字段也纳入索引末尾（如查 SELECT id, name, status FROM orders WHERE status = 'paid'，可建 (status, id, name)）
SQL改写比加索引见效更快，尤其对复杂查询
很多慢查询卡在逻辑写法上，不改语义也能大幅提速：
- 用 EXISTS 替代 IN（尤其子查询结果大时），IN 容易触发临时表或重复扫描；EXISTS 只需找到一条即停
- 拆分超长 UNION ALL：如果每个分支都带 LIMIT 和独立过滤条件，考虑改用临时表+INSERT SELECT 分批处理
- 避免 SELECT *，只取必要字段；大文本字段（如 content、remark）单独异步加载
- 分页深翻慎用 OFFSET：LIMIT 100000, 20 底层仍要跳过10万行。改用“游标分页”（如 WHERE id > last_seen_id ORDER BY id LIMIT 20）
统计信息不准？执行计划就容易“迷路”
PostgreSQL 和 MySQL 都依赖统计信息生成执行计划。大表数据批量导入/删除后，务必更新：
- MySQL：运行 ANALYZE TABLE table_name
- PostgreSQL：运行 VACUUM ANALYZE table_name（或定期开启 autovacuum）
- 观察 pg_stat_all_tables（PG）或 information_schema.STATISTICS（MySQL）确认索引使用率和数据倾斜情况
别忽略硬件与配置的“隐性瓶颈”
再好的SQL和索引，也可能被配置拖累：
- 检查 work_mem（PG）或 sort_buffer_size（MySQL）是否过小，导致外排序落盘
- 连接池设置不合理会导致并发查询堆积，监控 pg_stat_activity 或 SHOW PROCESSLIST 看是否有大量 Waiting 状态
- SSD磁盘 + 合理 shared_buffers / innodb_buffer_pool_size（建议设为物理内存的60%~75%）能显著减少IO等待
