按 ASC 排序比按 DESC 排序快 100 倍？为什么？

Question

我有一个由 Hibernate 为 JBPM 生成的复杂查询。我真的不能修改它，我正在搜索以尽可能地优化它。

我发现 ORDER BY DESC 比 ORDER BY ASC 慢很多，你知道吗？

PostgreSQL 版本：9.4 架构：https://pastebin.com/qNZhrbef 查询：

select 
taskinstan0_.ID_ as ID1_27_, 
taskinstan0_.VERSION_ as VERSION3_27_, 
taskinstan0_.NAME_ as NAME4_27_, 
taskinstan0_.DESCRIPTION_ as DESCRIPT5_27_, 
taskinstan0_.ACTORID_ as ACTORID6_27_, 
taskinstan0_.CREATE_ as CREATE7_27_, 
taskinstan0_.START_ as START8_27_, 
taskinstan0_.END_ as END9_27_,
taskinstan0_.DUEDATE_ as DUEDATE10_27_, 
taskinstan0_.PRIORITY_ as PRIORITY11_27_, 
taskinstan0_.ISCANCELLED_ as ISCANCE12_27_, 
taskinstan0_.ISSUSPENDED_ as ISSUSPE13_27_, 
taskinstan0_.ISOPEN_ as ISOPEN14_27_, 
taskinstan0_.ISSIGNALLING_ as ISSIGNA15_27_, 
taskinstan0_.ISBLOCKING_ as ISBLOCKING16_27_, 
taskinstan0_.LOCKED as LOCKED27_, 
taskinstan0_.QUEUE as QUEUE27_, 
taskinstan0_.TASK_ as TASK19_27_, 
taskinstan0_.TOKEN_ as TOKEN20_27_, 
taskinstan0_.PROCINST_ as PROCINST21_27_, 
taskinstan0_.SWIMLANINSTANCE_ as SWIMLAN22_27_, 
taskinstan0_.TASKMGMTINSTANCE_ as TASKMGM23_27_ 
from JBPM_TASKINSTANCE taskinstan0_, JBPM_VARIABLEINSTANCE stringinst1_, JBPM_PROCESSINSTANCE processins2_, JBPM_VARIABLEINSTANCE variablein3_ 

where stringinst1_.CLASS_='S' 
    and taskinstan0_.PROCINST_=processins2_.ID_ 
    and taskinstan0_.ID_=variablein3_.TASKINSTANCE_ 
    and variablein3_.NAME_ = 'NIR' 
    and taskinstan0_.QUEUE = 'ERT_TPS'
    and (processins2_.ORGAPATH_ like '/ERT%')
    and taskinstan0_.ISOPEN_= 't'
    and variablein3_.ID_=stringinst1_.ID_
order by stringinst1_.STRINGVALUE_ ASC limit '10';

解释 ASC 的结果：

 Limit  (cost=1.71..11652.93 rows=10 width=646) (actual time=6.588..82.407 rows=10 loops=1)
   ->  Nested Loop  (cost=1.71..6215929.27 rows=5335 width=646) (actual time=6.587..82.402 rows=10 loops=1)
         ->  Nested Loop  (cost=1.29..6213170.78 rows=5335 width=646) (actual time=6.578..82.363 rows=10 loops=1)
               ->  Nested Loop  (cost=1.00..6159814.66 rows=153812 width=13) (actual time=0.537..82.130 rows=149 loops=1)
                     ->  Index Scan Backward using totoidx10 on jbpm_variableinstance stringinst1_  (cost=0.56..558481.07 rows=11199905 width=13) (actual time=0.018..11.914 rows=40182 loops=1)
                           Filter: (class_ = 'S'::bpchar)
                     ->  Index Scan using jbpm_variableinstance_pkey on jbpm_variableinstance variablein3_  (cost=0.43..0.49 rows=1 width=16) (actual time=0.002..0.002 rows=0 loops=40182)
                           Index Cond: (id_ = stringinst1_.id_)
                           Filter: ((name_)::text = 'NIR'::text)
                           Rows Removed by Filter: 1
               ->  Index Scan using jbpm_taskinstance_pkey on jbpm_taskinstance taskinstan0_  (cost=0.29..0.34 rows=1 width=641) (actual time=0.001..0.001 rows=0 loops=149)
                     Index Cond: (id_ = variablein3_.taskinstance_)
                     Filter: (isopen_ AND ((queue)::text = 'ERT_TPS'::text))
                     Rows Removed by Filter: 0
         ->  Index Only Scan using idx_procin_2 on jbpm_processinstance processins2_  (cost=0.42..0.51 rows=1 width=8) (actual time=0.003..0.003 rows=1 loops=10)
               Index Cond: (id_ = taskinstan0_.procinst_)
               Filter: ((orgapath_)::text ~~ '/ERT%'::text)
               Heap Fetches: 0
 Planning time: 2.598 ms
 Execution time: 82.513 ms

解释 DESC 的结果：

 Limit  (cost=1.71..11652.93 rows=10 width=646) (actual time=8144.871..8144.986 rows=10 loops=1)
   ->  Nested Loop  (cost=1.71..6215929.27 rows=5335 width=646) (actual time=8144.870..8144.984 rows=10 loops=1)
         ->  Nested Loop  (cost=1.29..6213170.78 rows=5335 width=646) (actual time=8144.858..8144.951 rows=10 loops=1)
               ->  Nested Loop  (cost=1.00..6159814.66 rows=153812 width=13) (actual time=8144.838..8144.910 rows=20 loops=1)
                     ->  Index Scan using totoidx10 on jbpm_variableinstance stringinst1_  (cost=0.56..558481.07 rows=11199905 width=13) (actual time=0.066..2351.727 rows=2619671 loops=1)
                           Filter: (class_ = 'S'::bpchar)
                           Rows Removed by Filter: 906237
                     ->  Index Scan using jbpm_variableinstance_pkey on jbpm_variableinstance variablein3_  (cost=0.43..0.49 rows=1 width=16) (actual time=0.002..0.002 rows=0 loops=2619671)
                           Index Cond: (id_ = stringinst1_.id_)
                           Filter: ((name_)::text = 'NIR'::text)
                           Rows Removed by Filter: 1
               ->  Index Scan using jbpm_taskinstance_pkey on jbpm_taskinstance taskinstan0_  (cost=0.29..0.34 rows=1 width=641) (actual time=0.002..0.002 rows=0 loops=20)
                     Index Cond: (id_ = variablein3_.taskinstance_)
                     Filter: (isopen_ AND ((queue)::text = 'ERT_TPS'::text))
         ->  Index Only Scan using idx_procin_2 on jbpm_processinstance processins2_  (cost=0.42..0.51 rows=1 width=8) (actual time=0.003..0.003 rows=1 loops=10)
               Index Cond: (id_ = taskinstan0_.procinst_)
               Filter: ((orgapath_)::text ~~ '/ERT%'::text)
               Heap Fetches: 0
 Planning time: 2.080 ms
 Execution time: 8145.053 ms

表格信息： jbpm_variableinstance 12100592 行 jbpm_taskinstance 69913 行 jbpm_processinstance 97546 行

如果你有任何想法，谢谢

Answer 1

这通常仅在涉及 OFFSET 和/或 LIMIT 时发生（就像这里的情况一样）。

关键区别在于 EXPLAIN 查询输出中的这一行 DESC:

Rows Removed by Filter: 906237

意思是当索引 totoidx10 中的前 10 行在扫描 backwards 时匹配（显然这与你的 ASC 顺序匹配），Postgres 必须过滤 ~ 900k扫描相同索引时最终找到符合条件的行之前的行 forward.

匹配的多列索引（具有正确的排序顺序）可能会有很大帮助。
或者，由于 Postgres 选择了不利的查询计划，可能刚刚更新（或更详细）table 统计信息或成本设置。

按 ASC 排序比按 DESC 排序快 100 倍？为什么？

Order by ASC 100x faster than Order by DESC ? Why?

postgresql

optimization

performance

hibernate

sql-order-by