Oracle 时间戳列上的索引扫描

嗨，汤姆，

PFB查询结构:

select /*+ gather_plan_statistics  */    count(*)
FROM  CLPT INNER JOIN  SL 
ON CLPT.SHIPPER_LOT_ID = SL.ID 
AND CLPT.CLIENT_ID = SL.CLIENT_ID
WHERE  CLPT.CLIENT_ID = 3104 and CLPT.STATUS = 1 
AND CLPT.CREATED_ON >= TO_TIMESTAMP('01/01/2018 00:00:00', 'MM/DD/YYYY HH24:MI:SS')  
AND CLPT.CREATED_ON <= TO_TIMESTAMP('12/16/2018 23:59:59', 'MM/DD/YYYY HH24:MI:SS') ;

对于上述查询，有时索引跳过扫描发生在创建的索引on (CLIENT_ID，DEVICE_ID，CREATED_ON) 上，
有时不是。有时它用于创建索引的范围扫描 (CREATED_ON，CLIENT_ID，状态)，这是昂贵的，响应时间也更多。

=> 当optimiser使用跳过扫描时，响应时间是可以接受的。但是跳过扫描并不适用于所有客户端，主要用于全表扫描。

=> 如果我在提示中使用跳过扫描，则响应时间会更好，但是对于其他client_id来说却很昂贵。

=> SL表也适用于FTS。


日期是CLPT中的时间戳列。

CLPT中的总计数: 4727930
使用CLIENT_ID，状态和日期过滤器的总数，如上查询: 168025

CLPT上的索引为1。(创建 _ 开，客户端 _ id，状态)
2. (CLIENT_ID，DEVICE_ID，CREATED_ON)
其他列上的索引也是如此，但这里预计将在上述两个列之间使用。



SL上的索引: 1上的唯一索引。ID
2.客户id
3. (ID，CLIENT_ID，GROWER_ID)
其他列上的索引也是如此，但这里预计将在以上三个列之间使用。


请帮助进行适当的索引编制，或者是否存在与时间戳列有关的问题？

索引与时间戳列一起工作。我看到的唯一潜在问题是您正在选择大约一年的数据。这可能必须读取很多行!

要真正了解这里发生了什么，我们需要看看执行计划!

如果您使用此方法获得计划:

set serveroutput off

select /*+ gather_plan_statistics  */ ...

select * 
from   table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST'));

把它们贴在这里我们可以提供更有效的帮助。

也就是说，一些观察结果:

当索引的前导列具有相等 (=) 条件时，索引是最有效的。因此，将CLTP的索引1上的列重新排序为:

(CLIENT_ID,STATUS,CREATED_ON)

可能比你目前的指数更有效。

另外-如果您只计算行而不获取任何列-某种组合的索引:

(CLIENT_ID,STATUS,CREATED_ON,SHIPPER_LOT_ID )

应该启用仅索引扫描。避免表应该会使查询更快。

您为SL列出的三个索引中的任何一个都是此查询的候选索引。这使得优化器更难; 过时的统计数据可能会导致它选择 “错误” 的索引。

(ID，CLIENT_ID，GROWER_ID) 上的索引应该启用仅索引扫描。但由于这包括不必要的GROWER_ID列，它可能没有。再次，看到您的计划将对我们有所帮助!