i/o 问题：20000次i/o如何来的？

jiamiao442

emp表比较大时，而且deptno = 10条件能查询出表中大部分的数据如(50%)。如该表共有4000万行数据，共放在有500000个数据块中，每个数据块为8k，则该表共有约4G，则这么多的数据不可能全放在内存中，绝大多数需要放在硬盘上。此时如果该查询通过索引查询，则是你梦魇的开始。db_file_multiblock_read_count参数的值200。如果采用全表扫描，则需要500000/db_file_multiblock_read_count=500000/200=2500次I/O。但是如果采用索引扫描，假设deptno列上的索引都已经cache到内存中，所以可以将访问索引的开销忽略不计。因为要读出4000万x 50% = 2000万数据，假设在读这2000万数据时，有99.9%的命中率，则还是需要20000次I/O,比上面的全表扫描需要的2500次多多了，所以在这种情况下，用索引扫描反而性能会差很多。在这样的情况下，用全表扫描的时间是固定的，但是用索引扫描的时间会随着选出数据的增多使查询时间相应的延长。

这是我看sql优化看到的一段话，我的问题是这句话“假设在读这2000万数据时，有99.9%的命中率，则还是需要20000次I/O,比上面的全表扫描需要的2500次多多了” 这个“还需要20000次I/O”怎么来的？
----------------
思考：是不是，从索引中每查一条记录，就有一次io啊？那应该是2000万？也觉得不可能oracle没这么笨吧，那这个20000次是怎么来的呢？


[ 本帖最后由 jiamiao442 于 2011-11-18 10:00 编辑 ]

Maclean Liu(刘相兵

lz你好，

这个例子可能是要说明索引的适用场所，   对比的 是 全表扫描 和 INDEX FULL SCAN or INDEX RANGE SCAN 的效率

INDEX FULL SCAN 或 INDEX RANGE SCAN后会使用rowid 来访问表上的数据块，交叉访问 索引块和表块。 实际的成本受到clustering_factor 的影响， clustering_factor 可以详见我的一篇文章 <SQL调优:Clustering Factor影响数据删除速度一例> http://www.oracledatabase12g.com ... B8%80%E4%BE%8B.html



clustering_factor 的上限是 行数 (实际这里受到 查询条件的限制是2000万  下限是 表上的块总数

这里举的例子是 以 clustering_factor 为最大值的2000万 来说明 索引不适用于返回极大的结果集(50%) ，而实际的环境中 clustering_factor 未必是这么大的 ， 详见我的文章。

我想他的这个例子 仅仅是为了说明 那些场合下索引是不适用的， 但是一些细节因为没有具体说明所以并不明确。

laobu

当真是那样来的: 从索引中每查到一条记录，根据rowid再去访问对应的表块
在clusterfactor最大化的情况下，可不就是有那么些嘛

否则，还能怎么着呢