窗口函数排序不走B-tree索引是设计使然，因窗口作用域为全结果集，而索引仅保证扫描顺序；即使ORDER BY与索引完全匹配且无过滤干扰，也仅在极严格条件下（如无PARTITION BY、精确索引扫描）才可能跳过Sort节点。
窗口函数排序不走B-tree索引是设计使然，不是配置或写法问题
PostgreSQL 的窗口函数（如 ROW_NUMBER()、RANK()）在 ORDER BY 子句中指定排序逻辑时，不会复用已有 B-tree 索引的物理顺序。即使你对排序字段建了 B-tree 索引，执行计划里依然会出现 Sort 节点，且实际排序开销随结果集线性增长。
根本原因在于：窗口函数的排序作用域是「当前查询输出的全部行」，而 B-tree 索引只保证「按索引键顺序读取数据」——这两者语义不同。优化器无法把「先按索引顺序扫描 + 后续窗口计算」合并为一个无显式排序的操作，除非满足极严格的条件（见下一条）。
唯一能跳过 Sort 节点的情况：ORDER BY 与索引完全匹配且无过滤干扰
只有当同时满足以下全部条件时，PostgreSQL 才可能省略 Sort 节点，直接利用索引顺序：
- 查询的
ORDER BY字段顺序、方向（ASC/DESC）、空值处理（NULLS FIRST/LAST）与索引定义逐字一致 - WHERE 条件能通过索引扫描（Index Scan 或 Index Only Scan）精确限定行集，且不引入回表或随机访问
- 没有
LIMIT/OFFSET以外的其他逻辑干扰排序流（例如不能有GROUP BY在窗口之前） - 窗口定义中未使用
PARTITION BY，或PARTITION BY字段恰好是索引最左前缀列
例如：CREATE INDEX idx_events_on_time ON events (created_at DESC NULLS LAST);
对应查询：SELECT *, ROW_NUMBER() OVER (ORDER BY created_at DESC NULLS LAST) FROM events WHERE created_at > '2026-01-01';
此时有可能跳过 Sort；但只要加个 PARTITION BY user_id，就必然回归显式排序。
为什么 JSONB 字段排序必然触发 Sort，且无法索引加速
jsonb 类型本身没有默认 B-tree 排序规则，所以哪怕你给 data jsonb 建了 B-tree 索引，下面这句也一定报错：ROW_NUMBER() OVER (ORDER BY data) → ERROR: could not determine ordering of jsonb values
更关键的是，即使你用 ->> 提取出字符串再转类型（如 (data->>'score')::int），这个表达式本身已构成「索引列上的函数调用」，导致原生 B-tree 索引失效。必须另建函数索引才能支撑：CREATE INDEX idx_events_score ON events (( (data->>'score')::int ));
但注意：这个函数索引仅对等值或范围查询有效，对窗口函数中的 ORDER BY 仍不能跳过 Sort —— 因为窗口排序需要的是运行时全集有序，不是索引扫描路径。
OFFSET 分页 + 窗口函数 = 双重性能陷阱
如果在带 OFFSET 的分页查询里嵌套窗口函数（比如“查第10001–10020条，并标上全局排名”），PostgreSQL 会：
- 先扫描并丢弃前 10000 行（OFFSET 开销）
- 再对剩余行做完整排序（窗口 ORDER BY 开销）
- 最后才应用窗口函数计算
两个步骤都不可跳过，且 I/O 和内存压力叠加。实测中，OFFSET 超过 10 万后，响应时间常突破秒级。
真正可行的替代方案不是调优，而是重构：用游标分页（WHERE created_at ）替代 OFFSET，或把排名逻辑下推到应用层缓存。
窗口函数的排序行为是 PostgreSQL 查询执行模型的固有约束，不是 bug，也不是靠加索引就能绕过的。越早接受这点，越少在慢查询里反复折腾索引和 ANALYZE。
