Oracle11g Oracle计划与“Oracle计划”的差异；在；及；介于；

你能帮我做这个计划吗？我不明白。 我正在运行一个非常简单的请求：

SELECT *
FROM  BOOKING.BOOKING_GRID BG
WHERE BG.hotel=128 and day between 8600 and 8602;

另一个版本：

SELECT *
FROM  BOOKING.BOOKING_GRID BG
WHERE BG.hotel=128 and day in (8600,8601,8602);

我不明白为什么“中间”版本使用BOOKING\u GRID\u INDEX5，而“中间”版本不使用？表演很不一样！是因为物联网索引无法执行“范围扫描”吗

谢谢你的帮助

---

表索引为：

BOOKING BOOKING_GRIDPK  UNIQUE  VALID   IOT - TOP   N   NO      NO  HOTEL, DAY, BOOKINGSTATE    
BOOKING BOOKING_GRID_UNIQ   UNIQUE  VALID   NORMAL  N   NO      NO  HOTEL, DAY, BOOKING, VALIDITYSTART  
BOOKING BOOKING_GRID_INDEX5 NONUNIQUE   VALID   NORMAL  N   NO      NO  HOTEL, BOOKINGSTATUS, ISDAYUSE, DAY 
BOOKING BOOKING_GRID_INDEX7 NONUNIQUE   VALID   NORMAL  N   NO      NO  HOTEL, BOOKING, VALIDITYSTART   
BOOKING BOOKING_GRID_INDEX10    NONUNIQUE   VALID   NORMAL  N   NO      NO  HOTEL, ISDAYUSE, BOOKINGSTATUS, DAY 

这就是我得到的：

SQL> SELECT *
  2  FROM  BOOKING.BOOKING_GRID BG
  3  WHERE BG.hotel=128 and day between 8600 and 8602;

3584 ligne(s) sÚlectionnÚe(s).


Plan d'exÚcution
----------------------------------------------------------
Plan hash value: 1060169596

-----------------------------------------------------------------------------------------

| Id  | Operation         | Name                | Rows  | Bytes | Cost (%CPU)| Time     |

-----------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |                     |  6504 |   508K|   845   (5)| 00:00:11 |

|*  1 |  INDEX UNIQUE SCAN| BOOKING_GRIDPK      |  6504 |   508K|   845   (5)| 00:00:11 |

|*  2 |   INDEX SKIP SCAN | BOOKING_GRID_INDEX5 |   464 |       |   480   (7)| 00:00:06 |

-----------------------------------------------------------------------------------------


Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("BG"."HOTEL"=128 AND "DAY">=8600 AND "DAY"<=8602)
   2 - access("BG"."HOTEL"=128 AND "DAY">=8600 AND "DAY"<=8602)
       filter("DAY">=8600 AND "DAY"<=8602)


Statistiques
----------------------------------------------------------
         58  recursive calls
          0  db block gets
       6961  consistent gets
          0  physical reads
          0  redo size
     200030  bytes sent via SQL*Net to client
       3142  bytes received via SQL*Net from client
        240  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       3584  rows processed




SQL> SELECT *
  2  FROM  BOOKING.BOOKING_GRID BG
  3  WHERE BG.hotel=128 and day in(8600,8601,8602);

3584 ligne(s) sÚlectionnÚe(s).


Plan d'exÚcution
----------------------------------------------------------
Plan hash value: 1233826949

------------------------------------------------------------------------------------

| Id  | Operation         | Name           | Rows  | Bytes | Cost (%CPU)| Time     |

------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |                |  1869 |   146K|   681   (0)| 00:00:09 |

|   1 |  INLIST ITERATOR  |                |       |       |            |          |

|*  2 |   INDEX RANGE SCAN| BOOKING_GRIDPK |  1869 |   146K|    36   (0)| 00:00:01 |

------------------------------------------------------------------------------------


Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("BG"."HOTEL"=128 AND ("DAY"=8600 OR "DAY"=8601 OR "DAY"=8602))


Statistiques
----------------------------------------------------------
         57  recursive calls
          0  db block gets
        687  consistent gets
          0  physical reads
          0  redo size
     200192  bytes sent via SQL*Net to client
       3142  bytes received via SQL*Net from client
        240  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       3584  rows processed

---

我开始这样做：在处理一个离散的列表（这里只有3个值），其中两个之间必须考虑连续的范围。（请检查预期返回的行：例如，1869为中的行，6504为中的行。）

您的意思是什么？索引范围扫描（在请求计划中）不考虑连续值的范围吗？我不明白为什么会有什么不同。此外，请求之间计划中使用的双索引是否与错误的物理猜测问题有关？@RenaudBlue-否，索引范围扫描考虑的是一系列索引项，这些索引项可能完全不连续，如3、4、5、17、109等（请记住，它只存储表中的值）。考虑“连续”在数学中，8600和8602之间有无穷多的实数，而不是3。是的，我看到了枚举值和连续范围值之间的差异。但在这种情况下，天数是离散整数，上面有索引。所以我希望我能优化那里。。。我在第一个问题后面的问题是，我们在索引组织表中，为什么我要使用BOOKING\u GRID\u INDEX5和SKIP SCAN，而我只能使用主要的物联网索引BOOKING\u GRID\u PK@RenaudBlue-抱歉，我找不到关于优化器的IN-vs-BETWEEN的任何明确信息，但是在我的测试中，BETWEEN总是估计返回的行数更高（我使用的是数字（10））。至于跳过扫描，我同意奇怪的是它没有选择PK索引；也许试着暗示一下，看看你是否能强迫它。如果这有帮助的话，可能值得检查表/索引的统计信息。我已经添加了关于表n行和集群因子的信息。看到物联网的主要索引有这么大的聚类因子，我感到非常惊讶。还可以看出，二级索引的聚类因子可以比主索引低。你怎么认为？

Table       Index            Cluster. factor     Table NRows
BOOKING_GRID    BOOKING_GRID_INDEX7  276 816 902     313 290 258   
BOOKING_GRID    BOOKING_GRID_UNIQ    131 055 933     313 290 258   
BOOKING_GRID    BOOKING_GRID_INDEX10     121 702 397     313 290 258   
BOOKING_GRID    BOOKING_GRIDPK       108 115 708     313 290 258   
BOOKING_GRID    BOOKING_GRID_INDEX5   24 238 404     313 290 258