PostgreSQL 17.5分区表查询优化：无需UNION类语句提升慢查询性能

阿华AIGC实验室

2026-4-1

根据你提供的详细环境、表结构和执行计划，我来帮你拆解这个慢查询的问题根源，并且给出不需要依赖无效UNION ALL这种trick的正经优化方案：

一、问题根源分析

先复盘一下你的核心情况：

你有一个总大小150GB的按月分区表，其中table_partition202508是最大的分区（66GB）
慢查询是基于key IN (...)过滤+ORDER BY ts LIMIT 10，执行时间近5分钟
加了一个无数据的UNION ALL分支后，查询瞬间降到80ms左右

慢查询的执行计划坑点

慢查询中，PostgreSQL选择了(ts, key)的索引做反向扫描，这个选择看起来是想通过索引直接获取排序好的数据来避免排序，但实际上完全踩了坑：

这个索引的顺序是先ts后key，反向扫描时需要从最新的ts开始，逐个检查每条记录的key是否在指定列表中
因为符合条件的key对应的记录分散在整个时间范围内，数据库不得不扫描大量索引页（110万次磁盘读），大部分I/O都是无效的，这直接导致了执行时间爆炸

快查询的高效原因

加了UNION ALL后，优化器无法再用索引扫描直接满足ORDER BY + LIMIT的需求，只能走更合理的路径：

先用key的单列索引快速定位到所有符合key IN (...)的行（只有13076行，数量很少）
对这些少量数据用top-N heapsort排序（只需要27KB内存，完全在内存中完成）
启用了2个并行worker加速扫描，几乎所有操作都命中缓存，没有物理I/O

二、无需UNION的优化方案

下面是几个可以长期稳定解决问题的方案，不需要依赖临时的trick：

方案1：引导优化器使用`(key, ts)`复合索引

你已经创建了table_partition_key_ts_idx（key, ts）这个复合索引，这个索引的顺序完美匹配你的查询需求：

先按key过滤，快速定位到所有符合条件的行
这些行在索引中已经按ts排序好了，直接取前10条即可，不需要额外排序

可以用索引提示来强制优化器选择这个索引：

SELECT csh.key, csh.ts 
FROM table_partition202508 csh 
WHERE csh.key IN ('string1', 'string2') 
ORDER BY csh.ts 
LIMIT 10
-- 提示优化器使用key_ts_idx索引
INDEX USING table_partition202508_key_ts_idx;

如果索引提示生效，查询会直接通过这个索引获取排序好的前10条数据，性能和加了UNION的版本一样快。

方案2：重写查询，强制先过滤后排序

有时候优化器会因为LIMIT的存在，误判为走索引扫描更高效，我们可以用子查询明确告诉优化器：先过滤出所有符合条件的行，再排序取前10：

-- 子查询方式
SELECT key, ts
FROM (
    SELECT csh.key, csh.ts 
    FROM table_partition202508 csh 
    WHERE csh.key IN ('string1', 'string2')
) AS filtered_rows
ORDER BY ts 
LIMIT 10;

或者用MATERIALIZED关键字强制子查询先执行（适合符合条件的数据量确实不大的场景）：

SELECT key, ts
FROM (
    SELECT csh.key, csh.ts 
    FROM table_partition202508 csh 
    WHERE csh.key IN ('string1', 'string2')
) AS filtered_rows MATERIALIZED
ORDER BY ts 
LIMIT 10;

方案3：临时调整优化器参数（应急用）

如果上面的方案都不生效，可以临时调整优化器的参数，让它暂时不优先选择索引扫描：

-- 临时关闭当前会话的索引扫描（用完记得改回去）
SET enable_indexscan = off;

SELECT csh.key, csh.ts 
FROM table_partition202508 csh 
WHERE csh.key IN ('string1', 'string2') 
ORDER BY csh.ts 
LIMIT 10;

-- 恢复参数
SET enable_indexscan = on;

这个方案是临时的应急手段，不建议全局修改，因为会影响其他查询的执行计划。