我的排序键是否被使用？为何查询未利用updated_at排序键

这确实挺让人困惑的——明明给表设置了updated_at作为排序键，执行完VACUUM和ANALYZE后，范围查询居然还是走全表扫描。咱们一步步拆解可能的原因和解决办法：

1. 先确认统计信息是否真的准确 #

虽然你已经执行了ANALYZE，但有时候自动统计的粒度可能不够，或者数据更新后统计信息没有及时反映真实分布。你可以尝试针对性更新updated_at列的统计信息：

-- PostgreSQL/Greenplum 都适用
ANALYZE my_table(updated_at);
-- Greenplum 可以加VERBOSE查看详细过程
ANALYZE VERBOSE my_table;

查询优化器完全依赖统计信息判断执行计划，如果它认为updated_at > '2018-01-01'会返回大部分数据，就会选择全表扫描（因为此时索引扫描的回表开销反而更大）。

2. 别把“排序存储”和“索引”搞混了 #

你提到的“排序键”如果是指表创建时指定的物理排序存储（比如Greenplum的SORTED BY (updated_at)，或者PostgreSQL的CLUSTER操作），这只是让数据在磁盘上按updated_at有序排列，但它不是索引。数据库不会自动基于物理排序来做范围扫描的优化，除非优化器能明确利用有序性减少扫描范围（但这种场景很有限）。

如果你的查询是高频的范围过滤，建议直接给updated_at创建B-tree索引：

CREATE INDEX idx_my_table_updated_at ON my_table(updated_at);

创建完成后再执行EXPLAIN，大概率会看到索引扫描的计划。

3. 检查过滤后的数据占比 #

先跑两个统计查询，看看过滤条件返回的数据量：

-- 总数据量
SELECT COUNT(*) FROM my_table;
-- 过滤后的数据量
SELECT COUNT(*) FROM my_table WHERE updated_at > '2018-01-01';

如果过滤后的数据占总数据的30%以上，优化器选择全表扫描其实是合理的——因为索引需要先查索引条目，再回表取数据，这种情况下的IO开销比直接扫全表更高。

4. 验证排序键是否真的生效 #

最后确认一下你的表确实是按updated_at排序存储的，比如在PostgreSQL/Greenplum中查看表定义：

SELECT pg_get_tabledef('my_table');

检查输出里是否有SORTED BY (updated_at)（Greenplum）或者是否执行过CLUSTER my_table USING idx_my_table_updated_at;（PostgreSQL）。如果排序键根本没正确设置，那数据就是无序存储的，优化器自然不会利用它。

内容的提问来源于stack exchange，提问作者lfk