autotrace执行计划中，统计信息详解

全表扫描是怎么扫描的？

oracle最小的存储单位是block

物理上连续的block组成了extent（也就是说一个区中的全部块在物理上是连续的）

不少个extent组成了segment（一个segment中的区在物理上多是连续的，也多是不连续的）

全表扫描是一个区一个区的扫描的，由于一个区内多个块在物理上是连续的，因此能够多块读。

 

最经常使用的：set autotrace trace

统计信息的意义：

recursive calls ：递归调用的次数（递归调用是指，执行目标sql时，须要执行一些别的sql来为目标sql服务。eg：解析，查数据字典，插入数据字典，或目标sql中调用了用户自定义函数等）

通常一个新的sql执行2-3次之后递归调用次数就为0了，除非sql中有用户自定义函数。-----这个指标在优化中，通常不用过多关注。

db block get：有多少个块被修改了，单位是块（只有dml才能修改块，一个select语句通常状况下，db block get为0，当延迟块清除的时候，select 的 db block get可能不为0【延迟块清除没什么意义，不用过多关注】）

consistent get：逻辑读，一个块在buffer cache中，被扫描一次，逻辑读就+1，逻辑读多是读不一样的块，也多是一个块读了屡次。

【场景demo：若是一个表中好多的块都被修改过，在undo中，由于咱们要读undo，还要从新构造镜像块。因此，在一个高并发的dml情景下，select的逻辑读可能要比标准状况下高几倍。】

physical reads：物理读，将一个块从磁盘读到buffer cache，物理读+1.   （逻辑读是包含物理读的。）

redo size：跑这个sql产生多少的redo日志。（只要db block get为0，redo size为0）

这两个是网络指标，从服务器发送多少到客户端，从客户端接收了多少，不用过多关注。

sorts（memory）和sorts（disk）：内存排序和磁盘排序，优化中基本没用。不用关注。

1 rows processed（这一列是重点很是有用）：sql语句处理或返回了多少行，能直观的看出来，这个sql能不能优化。

 

【【【  重要的，有用的信息：consistent get 和 rows processed  】】】