olap查询慢首要检查执行计划中是否存在seq scan；若有，则需为高频聚合字段建b-tree/brin索引、避免索引列运算、设置语句超时、分离olap/oltp、合理使用物化视图与分区表，并调高统计信息采样率。
OLAP 查询慢，先看执行计划里有没有 Seq Scan 扫全表
OLAP 场景下查几十亿行数据，Seq Scan 几乎是性能杀手。它不走索引，直接读磁盘块，IO 和 CPU 双重开销。尤其当 WHERE 条件字段没建索引、或用了函数（比如 date_trunc('month', created_at)）导致索引失效时，PostgreSQL 就会退化成全表扫。
实操建议：
- 用
EXPLAIN (ANALYZE, BUFFERS)看真实执行路径，重点关注Rows Removed by Filter是否远大于最终返回行数——这说明过滤低效 - 对高频聚合维度（如
region_id、event_type）建B-tree或BRIN索引；BRIN 适合时间递增字段（如log_time），空间小、构建快 - 避免在
WHERE中对索引列做运算：WHERE to_char(created_at, 'YYYY-MM') = '2024-01'会跳过索引，改成WHERE created_at >= '2024-01-01' AND created_at
OLTP 查询突然变慢，检查是否被 OLAP 查询锁住 pg_locks
OLTP 事务短平快，但一个未提交的 OLAP 查询（比如漏写 COMMIT 的长事务）可能持有 AccessShareLock 或更重的锁，阻塞后续 DML。现象是 UPDATE 或 DELETE 卡住，pg_stat_activity 显示状态为 active 且 wait_event_type = 'Lock'。
实操建议：
- 定期查
SELECT pid, query, state, wait_event_type FROM pg_stat_activity WHERE state = 'active' AND now() - backend_start > interval '5 minutes' - 对 OLAP 查询显式加超时：
SET statement_timeout = '300000'（5 分钟），避免失控 - OLAP 和 OLTP 应分库或至少分用户，用
pg_hba.conf限制 OLAP 用户无权执行UPDATE/DELETE
用 MATERIALIZED VIEW 加速固定报表，但要注意刷新时机
MATERIALIZED VIEW 能把复杂聚合结果固化下来，查起来飞快，但它不是自动更新的。如果业务要求“近实时”，而你用 REFRESH CONCURRENTLY 每小时刷一次，那凌晨三点刷表期间，SELECT 可能等锁，或者看到旧数据。
实操建议：
- 只对查询模式稳定、更新频率明确（如每天一次）的报表建物化视图；别给每张事实表都建
- 用
REFRESH CONCURRENTLY避免锁表，但要求目标视图有唯一索引，且 PostgreSQL ≥ 9.4 - 刷新任务别堆在整点：用
pg_cron错峰执行，比如随机延后 0–15 分钟，防止单点压力突增
分区表在 OLAP 中有用，但别迷信 LIST 分区
按地区、状态等离散值做 LIST 分区，看起来直观，但实际容易失衡——比如 status IN ('pending', 'processing', 'done')，其中 done 占 95% 数据，查询时仍要扫描大分区。而 RANGE（按时间）或 HASH（按 ID）更容易做到数据均匀和剪枝精准。
实操建议：
- 时间类 OLAP 表优先用
RANGE分区，配合ATTACH/DETACH快速滚动窗口（如每月删旧、加新） - 用
pg_partition_tree()查分区是否真正生效；有时WHERE条件写成created_at::date = '2024-01-01'会导致分区剪枝失败 - 分区键必须出现在
WHERE条件中才能剪枝，否则和普通表没区别
最常被忽略的一点：OLAP 和 OLTP 共用同一套统计信息（pg_stats），而 ANALYZE 默认采样率对大表偏低。不手动调高 default_statistics_target，优化器就容易选错执行计划——哪怕你建了索引、写了正确条件，它还是扫全表。
