High Waits on 'Db File Sequential Read' Due

SELECT D
FROM BIG_TABLE
WHERE A = 1253
AND B in ('CA', 'CO')
AND C > 210 ;

Rows    Row Source Operation
------- ---------------------------------------------------
 215431 TABLE ACCESS BY INDEX ROWID BIG_TABLE (cr=880191 pr=430780 pw=0 time=2293667056 us) 

<p></p>
<p>在大多数这样的例子中，执行查询语句在“<span>TABLE ACCESS BY INDEX ROWID</span>”上的等待要比<span>INDEX SCAN上需要更多的。这是因为随机访问表行的代价要比索引扫描更大。</span></p>
<p><span><br>
</span></p>
<p><span>为此，可以有以下几种方法调试：</span></p>
<p>1. 检查是否有更好的索引或执行计划。可能需要重新设计索引。</p>
<p>2. 尝试全表扫描。全表扫描通常比索引扫描要快，尽管CBO成本比索引扫描的成本高。</p>
<p><span>SELECT /*+ FULL(BIG_TABLE) */  D </span><br>
<span>FROM BIG_TABLE </span><br>
<span>WHERE A = 1253 </span><br>
<span>AND B in ('CA', 'CO') </span><br>
<span>AND C > 210 ;</span><br>
</p>
<p>3. 如果仅仅有很少的列出现在SELECT和WHERE子句中，可以考虑为查询创建一个复合索引避免回表。</p>
<p>例如：</p>
<p><code>CREATE INDEX <index_name> ON BIG_TABLE (A, B, C, D);</index_name></code></p>
<p><span>注意：仅针对SELECT语句有效。如果是UPDATE语句，这种做法可能没用。</span></p>
<p><span>4. 将表移动到更大block块大小的表空间。更大的block块会有更多的行，所以对减少block块IO会有帮助。重新组织表也会有帮助，因为这样做可以让索引有一个更小的clustering聚类因子。</span></p>
<p><span>5. 可以考虑增加buffer cache的大小，以至于可以缓存更多的块大小。如果表是频繁访问的，使用keep buffer池也是一个不错的选择。</span></p>
<p><span>6. 考虑使用IOT(索引组织表)。IOT可能减少IO，原因就是他会将数据存储于一个B树索引结构。例如，如果A列是表BIG_TABLE的主键，可以按照如下方法创建IOT：</span></p>
<p><span><span>create table BIG_TABLE (A number primary key, B char(2), C number, D varchar2(10))</span><span> organization index;</span></span></p>
<p><span><span>7. 如果服务器有足够的空闲资源(CPU，内存)，考虑使用并行执行。这种方式不会减少IO，但是有助于降低执行时间。</span></span></p>
<p><span><span>8. 较差的磁盘IO也可能是一个原因。可以提高表所在磁盘设备的IO。这可能需要系统管理员的协助。</span></span></p>