大表查询慢的核心是减少数据扫描量和优化执行计划；需结合执行计划分析、精准建索引（等值>范围>排序）、更新统计信息、调优硬件与配置参数。
大表查询慢，核心就两件事：让 数据库 少扫描数据、让执行计划走对路。索引不是加了就快，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 和索引，也可能被配置拖累：
