关于orqcle查询不走索引问题

sql无法上传，只能用图片的方式展现问题。
主要是关于oracle查询在一定数量量时不走索引问题

img

img

你这代码看起来怪怪的，想统计索引a乘以记录的数量的总和？不走索引的情况是sql语句常有的事情，可能在表中具有较多匹配值的索引（如123、234和345），456匹配的记录较少。这时候只会索引扫描而不是使用索引来加速查询。确保内存宽裕的情况下，使用ANALYZE TABLE来重新统计信息。


SELECT
/*+index(a index1)*/
    count(*) 
FROM
    tabA a inner join 
    tabB b on a.c1 = b.l1 
WHERE     a.c3 BETWEEN lpad(     to_char ( b.13 ), 8, 0) and lpad( to_char ( b.l4 ), 8, 0 ) 
        AND b.l2 IN ('123', '234,345)

可以使用in 和 exists 分别查看执行计划。

参考GPT：
oracle查询不走索引的情况可能有多种原因，导致索引失效或被忽略，影响查询性能。一些常见的原因有：
查询条件没有使用索引列：如果查询条件没有涉及到建立了索引的列，或者没有使用组合索引的第一列，那么就无法利用索引进行查询优化。
查询条件使用了函数或运算：如果查询条件对存在索引的列使用了函数或运算，那么就会使优化器忽略这些索引，除非使用了基于函数的索引。
查询条件使用了前导模糊查询：如果查询条件使用了LIKE '%T’这样的前导模糊查询，那么就会导致不走索引，因为无法定位到具体的匹配范围。
查询条件使用了不等于或NOT IN/NOT EXISTS：如果查询条件使用了不等于或NOT IN/NOT EXISTS这样的操作，那么就会导致不走索引，因为这样的操作会返回结果集中的大部分数据，优化器可能认为全表扫描更快。
表中数据量太少或太多：如果表中数据量太少，那么优化器可能认为全表扫描更简单；如果表中数据量太多，而且查询返回的数据占比超过30%，那么优化器可能认为全表扫描更有效。
比较不匹配类型的数据类型：如果查询条件和索引列的数据类型不匹配，那么就会导致隐式类型转换，从而限制了索引的使用。
等于和范围索引不会被合并使用：如果在同一个查询中同时使用了等于和范围索引，那么只有等于索引会生效，范围索引会被忽略。
要解决oracle查询不走索引的问题，可以尝试以下几种方法：
选用合适的Oracle优化器：Oracle优化器有三种，一种是基于规则的（RULE），一种是基于成本的（COST），还有一种是选择性的（CHOOSE）。在缺省的情况下（未设置），Oracle默认采用CHOOSE优化器。为了避免那些不必要的全表扫描（FULL TABLE SCAN），可以尝试直接采用基于规则或基于成本的优化器。
重建索引：有时候索引可能因为某些原因失效或损坏，可以尝试重建索引来恢复其功能。
强制索引：如果确定某个索引对查询有利，但是优化器没有选择它，可以尝试使用hint关键字来强制使用该索引。

重建索引试过？，可能数据发生变动，导致索引无效了，可以重建索引，再试试

  • 你可以看下这个问题的回答https://ask.csdn.net/questions/7424486
  • 这篇博客也不错, 你可以看下只是简单读了读《oracle查询优化改写》，就让我获益匪浅，想写好sql，这一本书就够了！
  • 除此之外, 这篇博客: 删库跑路如何预防？—— Oracle创建只读账号详细教程中的 第八步：执行删除、修改sql语句测试 部分也许能够解决你的问题, 你可以仔细阅读以下内容或跳转源博客中阅读:

  • 以下回答由chatgpt基于相关博客总结生成:

    根据提供的图片，分析了一下查询语句和问题描述，得出以下结论：

    1. 查询语句中使用了多个子查询和连接操作，可能会影响查询性能。
    2. 子查询中使用了对日期进行计算和转换的操作，可能会导致索引无法生效。
    3. 查询表中存在的时间字段没有使用索引，导致查询速度较慢。

    解决方案如下：

    1. 尽量减少子查询和连接操作：可以考虑将查询语句拆分成多个简单的查询语句，并通过使用WITH语句或者临时表来优化查询性能。
    2. 避免在检索字段上进行函数运算：例如，在子查询中对时间字段进行转换，建议将时间字段转换为合适的格式存储到新的列中，然后对新列进行索引和查询操作。
    3. 确保查询的时间字段存在索引：可以通过检查表的索引信息或者手动创建索引来确保时间字段的索引存在并且能够被查询使用。
    4. 考虑调整查询语句中的条件和排序规则：可以通过优化WHERE条件和ORDER BY子句来进一步提升查询性能。

    由于无法上传SQL代码，无法对具体的查询语句和数据库结构进行更详细的分析和优化，建议根据以上提供的解决方案进行相关调整和优化尝试，或者提供更多详细的信息以便进一步分析和优化。

基于bing、GPT部分内容和本人思考总结：
我可以为你提供一些关于Oracle查询不走索引的常见原因和解决方法：

统计信息过期：Oracle使用统计信息来选择执行计划，如果统计信息过期或不准确，可能导致查询不走索引。你可以使用DBMS_STATS包中的GATHER_TABLE_STATS过程来收集更新统计信息。

数据分布不均匀：如果数据在索引列上的分布极不均匀，查询可能更倾向于全表扫描而不是使用索引。可以考虑重新构建索引或使用索引提示来强制使用索引。

查询条件不使用索引列：如果查询条件没有使用到索引列，那么索引将无法发挥作用。请确保查询条件涉及到索引列，并且使用合适的操作符。

存在隐式类型转换：如果查询条件中的数据类型与索引列的数据类型不匹配，Oracle可能会进行隐式类型转换，导致索引无法使用。要避免这种情况，可以显式地进行类型转换。

系统参数设置不正确：某些Oracle系统参数（如OPTIMIZER_MODE、OPTIMIZER_INDEX_COST_ADJ等）的设置可能影响查询计划选择。请确保这些参数配置正确。

索引碎片化：索引碎片化可能导致索引性能下降，查询不走索引。可以使用ALTER INDEX ... REBUILD命令来重建索引。

以上是一些常见的原因和解决方法，但具体问题需要根据实际情况进行分析和调整。如果问题仍然存在，请提供更多详细信息，我将尽力帮助你解决。

可以使用explain关键字查看一下SQL语句的执行计划，是否走索引。

有两种可能，1.在in中增加456后，符合 123,234,345,456的记录超过总记录10%,执行计划变为全表扫描。
2.456的记录是后来插入的，统计信息里不存在记录。执行计划走全扫。
建议，生产2个语句执行计划印证一下，收集统计信息再试一下。最好贴一下10053trc看一下内部解析。

oracle查询不走索引的一些情况（索引失效）
可以参考这个例子


https://www.dbs724.com/88361.html