Oracle性能分析4：数据访问方法之全扫描

SQL语句执行时，Oracle的优化器会根据统计信息确定表的访问方式，一般来说，有两种基本的数据访问方式：1）全扫描。在全扫描（全表扫描或者快速全索引扫描）中，多个块被读入到一个IO运算中。2）索引扫描。索引扫描首先扫描索引叶子块以取得特定的行id（rowid），然后利用这些行id来访问父表取得实际的行数据，访问通过单块读取来完成。这里主要讲解全扫描方式，后面将介绍索引扫描。

使用全扫描

当对一个表进行全扫描时，会将表中所有数据块（block）取出并进行处理，筛选出符合条件的数据。注意Oracle必须将整个数据块（block）中的数据读到内存中，再取得符合条件的数据。因此Oracle的优化器需要关心两个信息：获取块的数量和每个块中舍弃的数据量。优化器将根据这两个信息来判断是否使用全扫描，首先我们来看看获取块的数量怎么影响优化器的选择。

获取块的数量

总的来说，如果查询需要取出表的大部分数据块，则应该采用全扫描。但由于很难评估查询将取出的表的数据块的数量，因此在使用全扫描上存在很多这样的“经验法则”：当你的查询会取出表中x%的数据行，则应该选择全扫描。这些法则有一定的道理，但是并不准确，因为当取出的数据行较大时，自然取出的数据块也会较大，这时采用全扫描并没有问题，但有时虽然取出的数据行较小，会取出的数据块也可能会较大，实际上这时也应该采用全扫描，但这些“经验法则”则不再生效。我们看看下面具体的例子。

我们创建一个表T1：

create table t1 as
select trunc((rownum - 1) / 100) id, rownum value
from dba_source
where rownum <= 10000

然后为T1创建索引：

create index idx_t1_id on t1(id)

然后为T1收集统计信息：

BEGIN
dbms_stats.gather_table_stats(user,
't1',
method_opt => 'FOR ALL COLUMNS SIZE 1',
cascade    => TRUE);
END;

然后我们执行查询：

select * from t1 where id = 0

该查询的执行计划如下：

SELECT STATEMENT, GOAL = ALL_ROWS
TABLE ACCESS BY INDEX ROWID
INDEX RANGE SCAN

该执行计划使用了索引范围扫描，由于符合条件id为0的数据在表中只有100行数据，而整个表有1万行数据，查询出的数据只占整个数据的1%，因此我们认为这是一种合理的执行计划。

接下来我们看下面的例子，创建一个表格T2：

create table t2 as
select mod(rownum,100) id, rownum value
from dba_source
where rownum <= 10000

同样为T2创建索引：

create index idx_t2_id on t2(id)

然后为T2收集统计信息：

BEGIN
dbms_stats.gather_table_stats(user,
't2',
method_opt => 'FOR ALL COLUMNS SIZE 1',
cascade    => TRUE);
END;

然后执行查询：

select * from t2 where id = 0

该查询的执行计划如下：

SELECT STATEMENT, GOAL = ALL_ROWS
TABLE ACCESS FULL

我们看到表的执行计划变成的全表扫描，我们可以很容易的得到该查询的结果任然是100条数据，占T2表总数据量的1%，如果我们进一步比较T2和T1的数据，会发现两张表的id字段完全一样，那为什么T1选择的是索引扫描，而T2却选择了全表扫描呢？

要了解原因，我们需要从数据在数据块上的分布来分析，在T1表中，id字段的分布如下：

0 0...0 0 1 1...1 1 2 2...2 2......88 88...88 88......99 99...99 99

而T2表中id字段的分布如下：

0 1 2 3 ... 98 99 0 1 2 3 ... 98 99 ...... 0 1 2 3 ... 98 99

从这里可以看出T1表中id为0的数据都集中在几个数据块上，而T2表中id为0的数据则分布在很多不同的块上，这样导致T1的查询只需要读取很少块就可以得到结果，因此使用了索引范围扫描，而T2上的查询则需要读取大部分块，因此优化器选择了全表扫描。

舍弃

需要注意的是，全扫描的效率不仅取决于读取的数据块个数，也取决于最终的结果集行数。从上面的例子中我们可以看到：当一个数据块被读取后，查询将根据过滤条件舍弃不符合条件的数据。而这个舍弃的过程是需要耗费资源的，由于这个操作在内存中，因此耗费的将是CPU资源，而舍弃的数据量越大，耗费的CPU资源就越多。

因此，读取的数据块的个数越多，舍弃的数据量越大，全扫描的成本（cost）就越高。

不难想象，当表的数据量不断增大，舍弃的行的数量不断增加，全扫描的成本不断增加，最终可能导致优化器放弃全扫描，转而选择索引扫描。

多块读取方式

多扫描使用的是多块读取，即一个单独的IO调用将会读取多个块，读取的块的数量是可变的，但有一个上限，通过db_file_multiblock_read_count参数指定，该参数通过下面的SQL查看：

select * from v$parameter where name = 'db_file_multiblock_read_count'

下面描述了Oracle在几种情况下读取的块的数量：

 1）Oracle不得不读取超过一定边界范围的数据块。

 在这种情况下，Oracle将会在一次调用中读取直到边界范围的数据块，然后发起另一次调用来读取剩下的块。

 2）存在块已经在内存中

 首先读取那么已经在内存中的块，然后发起调用读取剩下的块，这意味着多块读取可能一次仅读取一块。例如，假定多块读取的上限是16，该次读取的数据块编号为1-16，并且编号为偶数的块已经在内存中，那么在这里例子中，将会有8次的单块读取调用来读取奇数编号的块。

 3）多块读取大小超过了操作系统限制

 这时取决于你操作系统，因此是可变的。

高水位线

所谓高水位线，就是表中最后一块有数据写入的数据块。需要注意的是即使几乎所有数据行都被删除了，并且一些块实际上已经完全变为空的了，高水位线还是保持不变。看下面的例子，当表创建并插入数据后：



而随着后面数据的变化（删除和修改），表中的数据变化为：



虽然很多存储区域已经没有数据，但高水位线任然保持不变。

那么，高水位线对全扫描会造成什么影响呢？

执行全扫描时，Oracle将一直读取到位于表中高水位线的数据块，即使它们是空的，这就意味着许多实际上不需要读取的数据块也被读取了。

下面通过一个具体的实例来看，使用先前的表T2。

1）通过下面的语句判断表所包含的数据块数量：

select blocks from user_segments where segment_name = 'T2'
结果：24

2）确定表中有多少数据块包含数据；

select count(distinct(dbms_rowid.rowid_block_number(rowid))) block_ct from t2
结果：17

3）执行下面的查询，并查看trace信息（trace信息的获取方面见Oracle性能分析1）

alter system flush buffer_cache;--清理缓存
select * from t2 where id = 0

trace信息为：

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.06         18         20          0         100
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.00       0.07         18         20          0         100

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 5

Rows     Row Source Operation
-------  ---------------------------------------------------
100  TABLE ACCESS FULL T2 (cr=20 pr=18 pw=0 time=35975 us)

查询出100行数据，物理读取的数据块数量（disk）为18，包括一个表头数据块的读取（只有17个数据块包含数据）。执行计划使用了全表扫描。

4）执行删除数据的操作

delete from  T2

5）重新获取表包含的数据块数量

select blocks from user_segments where segment_name = 'T2'
结果：24

6）获取包含数据的数据块数量

select count(distinct(dbms_rowid.rowid_block_number(rowid))) block_ct from t2
结果：0

7）执行查询并查看trace信息

alter system flush buffer_cache;--清理缓存
select * from t2 where id = 0

trace信息为：

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.21         18         20          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.00       0.22         18         20          0           0

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 5

Rows     Row Source Operation
-------  ---------------------------------------------------
0  TABLE ACCESS FULL T2 (cr=20 pr=18 pw=0 time=214806 us)

我们可以看到查询出的行数是0，但任然物理读取了18个数据块，执行计划任然使用了全扫描。

修正高水位线

我们已经了解了高水位线给全扫描带来的性能问题，下面介绍了几种降低高水位线的方法。

使用truncate操作

truncate table_name

在删除数据时尽量使用truncate操作，降低高水位线。

move操作

alter table table_name move

注意move操作需要使用额外的表空间存储，会锁住表，这样其他并发的用户在表上执行的DML语句会产生等待。move操作会影响到表上的索引，因此索引需要rebuild。

shrink操作

shrink space操作，不需要任何额外的空间，但是速度要比move慢上很多。shrink命令分为下面两种：

1）只压缩空间不调整水位线，在业务繁忙时可以执行

alter table table_name shrink space compact

compact操作通过一系列insert、delete操作，将数据尽量排列在段的前面。在这个过程中需要在表上加RX锁，即只在需要移动的行上加锁。但由于涉及到rowid的改变，因此需要enable row movement。

2)调整水位线  会产生锁，可以在业务比较少的时候执行，oracle 会记住1步骤中的操作，只调整水位线

alter table big_table shrink space

使用新表

复制要保留的数据到临时表t，drop原表，然后rename临时表t为原表。