Laurenz Albe：降序索引的优势
内容提要
PostgreSQL 的 B-tree 索引可双向扫描，通常无需 DESC 索引；但混合升降序 ORDER BY 必须使用 DESC。降序插入时降序索引填充更紧凑、体积更小；顺序扫描降序索引比反向扫描升序索引更快，得益于 Linux 预读优化。
延伸解读
何时必须使用降序索引
PostgreSQL 的 B-tree 索引可以双向扫描，因此单纯的 ORDER BY ... DESC 通常不需要降序索引。但是，当 ORDER BY 子句混合了升序和降序列时，索引的排序方向必须与 ORDER BY 完全匹配，此时必须使用 DESC 子句创建降序索引。例如，ORDER BY a ASC, b DESC 需要索引 (a ASC, b DESC)。
降序索引的存储优势
如果数据按降序插入，降序索引的页面填充更紧凑，体积更小。这是因为 B-tree 索引对在末尾插入进行了优化：当分裂最右侧页面时，会将大部分条目放入较低页面，而不是平均分配。对于升序索引，降序插入会导致页面分裂时留下更多空闲空间，从而增大索引体积。
顺序扫描的性能差异
在需要大量降序扫描时，降序索引可能比反向扫描升序索引更快。文章中的测试显示，在 NVMe 磁盘上，反向扫描升序索引的耗时几乎是正向扫描降序索引的十倍。这主要得益于 Linux 的预读机制：内核检测到顺序读取时会提前发出 I/O 请求，而反向扫描无法有效利用这一优化。
Q&A
PostgreSQL 的 B-tree 索引可以双向扫描，那为什么还需要创建降序索引？
虽然 B-tree 索引可以双向扫描，但在某些情况下仍需降序索引：一是当 ORDER BY 子句包含混合升降序（如 ORDER BY a ASC, b DESC）时，必须使用降序索引才能精确匹配排序顺序；二是在降序插入数据时，降序索引填充更紧凑、体积更小；三是顺序扫描降序索引比反向扫描升序索引更快，得益于 Linux 预读优化。
在 PostgreSQL 中，什么情况下必须使用 DESC 索引？
当查询的 ORDER BY 子句包含混合升降序时，必须使用 DESC 索引。例如 ORDER BY a ASC, b DESC，需要创建索引 (a ASC, b DESC) 才能支持该排序。如果只使用升序索引，无法精确匹配这种混合排序。
降序索引在插入数据时为什么比升序索引更节省空间？
因为 B-tree 索引针对在末尾插入进行了优化。当插入降序数据时，降序索引的“最右”页包含最小的值，因此优化生效，页面填充更紧凑。而升序索引在插入降序数据时，页面分裂会平均分配条目，导致一半空间空闲，索引体积更大。
顺序扫描降序索引比反向扫描升序索引快吗？为什么？
是的，顺序扫描降序索引通常更快。这是因为 Linux 的预读机制：当内核检测到顺序读取文件时，会自动预取后续页面，减少 I/O 等待。反向扫描升序索引无法触发预读，导致性能下降。在 NVMe 磁盘上，反向扫描可能比正向扫描慢近十倍。
PostgreSQL 的 B-tree 索引在页面分裂时有什么特殊优化？
B-tree 索引针对在末尾插入进行了优化。当分裂最后一个索引页时，会将大部分条目放入较低的页面，而不是平均分配。这有利于序列生成的键或递增时间戳的典型场景。对于降序索引，当插入递减数值时，该优化同样有效。
降序索引在哪些实际场景中能带来性能提升？
降序索引在以下场景能提升性能：1) 支持混合升降序的 ORDER BY 子句；2) 降序插入数据时，索引更紧凑，节省空间；3) 需要执行大量降序索引扫描时，顺序扫描降序索引比反向扫描升序索引更快，尤其当数据不在缓存中时。
