快晕倒了！加上order by解释计划竟然不一样！

显示全部楼层 · 2012-10-9 18:05:37

请教各位高手一个问题，我们实在没有办法了，百思不得其解。我们有一个再简单不过的SQL语句：
select * from table01 where ResultId = '123456' order by NumberType;
这个ResultId上有索引，可是解释计划就是全表扫描，我们试来试去，发现如果去掉order by 子句，解释计划就用上了索引。我们的表没有做过分析，使用的是优化策略是CHOOSE，索引重建过了，还是一样。
请教各位，会是什么原因？谢了！

千问 · 2012-10-9 18:05:37

排序是不会走索引的

千问 · 2012-10-9 18:05:37

我们在另外一个数据库上执行同样语句，就可以使用索引，所以排序可以使用索引。两个数据库，同样的表，只有表里的数据量不一样，其他都一样，这也让我们很是疑惑。

千问 · 2012-10-9 18:05:37

最初由 aboul 发布
[B]排序是不会走索引的 [/B]
这个说法肯定是8对的

千问 · 2012-10-9 18:05:37

数据量小时,优化器自动选择,会认为全表扫描比索引访问更快,
而数据量大时,索引访问比全表扫描快

千问 · 2012-10-9 18:05:37

最初由 paulyibinyi 发布
[B]数据量小时,优化器自动选择,会认为全表扫描比索引访问更快,
而数据量大时,索引访问比全表扫描快 [/B]
这个说法也是有问题的
确实，数据量小时，oracle会选择全表扫描。那到底多小？就是整个表的block比db_file_multiblock_read_count还小时，只要一次IO就可以读全部表，那么无论咋样，oracle都会选择全表扫描，因为什么索引也不能做到一次IO就取到数据，对吧

而数据量大时，就选择索引？这个就未必了，你访问整个表的全部数据，索引扫描还会比全表扫描有效么？你索引的聚合因子等于数据行数的时候，这个索引在大范围扫描的时候效率还会高么？呵呵
优化器的选择，要考虑很多因素的，不是简单的一个定式就可以说明问题的。
至于oracle为什么选择某条路径，可以通过10053事件来获得一些信息
另外，楼主最好分析一下表看看分析后的路径

千问 · 2012-10-9 18:05:37

没有分析肯定有问题啊，选choose就是表扫描了

千问 · 2012-10-9 18:05:37

我们两个数据库，有一个数据库的这个表的数据量比较小，13866814行数据，在这个库里，同样的语句可以用到索引，另一个数据库的表比较大，27069809行数据，就用不到索引。但是不管哪个库，我都不认为ORACLE可以在一次IO中判断出应该全表扫描，照它们的数据量，理应全部使用索引才对。另外，我们无法修改程序，无法修改库表结构，只能指望在操作系统层面、数据库参数层次解决这个问题，因为同类的问题太多，我们没法一个一个地改过去，系统太大了，哪改得过来。当年咱们学习SQL语句，可没有人说这个ORDER BY 还跟数据量有关的！

千问 · 2012-10-9 18:05:37

贴出两个DB上的SQL 执行计划

千问 · 2012-10-9 18:05:37

象你這種情況CBO的話作分析是最快的解決方法了.
不方便作分析就用hint,指定他使用哪個索引,或者用存储大纲.