Oracle执行计划与代价评估-优快云博客

2019独角兽企业重金招聘Python工程师标准>>>

Oracle的代价

首先测试一下Oracle对代价COST的判断是否准确，这样多少让我们对Oracle数据有些信心。

我们知道在表有索引的情况下，Oracle可以选择索引读，也可以选择全表扫描，这是两种截然不同的执行计划，不见得一定是索引读胜过全表扫描，有时候索引读的效率会比全表扫描低，所以Oracle的选择不是看是什么执行计划，而是判断谁的代价更低。

来做一组实验来证实一下Oracle的代价判断是否准确，前面证实了执行某sql语句后，在继续执行同样的sql指令，性能会大幅度的提高。

现在还是继续这个例子，同样的t表，同样的sql语句，但是我要加上一个HINT(什么是HINT，就是一种强制写法，比如强行让某sql语句不走索引，或者强行让某sql语句走某索引)，原来的sql语句是select object_name from t where obejct_id=29;

现在，我增加/*+full(t)*/的写法，来强制该sql语句不走索引，走全表扫描，具体如下:

select /*+full(t)*/ object_name form t where object_id=29;

执行这个语句的目的是看看，Oracle选择索引是否是明智的选择，是否会更快，逻辑读等是否都少的多。

由此我们的得出结论，Oracle对代价的评估和判断是相当准确的，这个实验证明了Oracle数据库还是可以信赖的，我们可以充分相信它的选择，只是它的选择比较艰难，开销很大，如果他们选择的结果能够保留下来重用，那么艰难的动作就可以避免重复操作，性能就会大幅度的提升了，Oracle在这方面的设计确实很巧妙。

下面来继续描述体系结构，我们以修改语句update t set object_id=92 where object_id=29为例，回想之前的的select object_name from t where obejct_id=29,可以很清楚地想象到这个update语句的前后经历：

1. 如果该用户并没有退出原连接去新建一个连接，PGA区的用户连接信息和权限判断等诸多动作依然不用做，否则需要完成用户连接信息和权限判断等诸活动。

2. 如果该语句是第一次执行，在共享池里依然需要完成语法语义分析及解析，update t set obejct_id=92 where object_id=29;指令中想匹配到object_id的记录既可以用索引读，也可以用全表扫描，到底选用哪种执行计划需要根据代价的大小来选择。

3. 接下来进入数据缓冲区，首次执行该数据一定不在缓冲区里，也是和前面一样，先从磁盘中获取到缓冲区中.......

以上三点和之前的select object_name from t where object_id=29 描述几乎没有任何本质区别，差异在于查询语句做完这三步后，返回数据结果给用户，就结束了，而更新语句的工作确远没有结束，还要继续工作。

接下来，更新语句要完成什么工作呢？

这次涉及到DBWR进程，其实描述起来很简单，就是在数据缓冲区内修改完数据后，会启用DBWR进程，完成更新的数据从内存中刷入到磁盘中，将磁盘中的29修改成92，因为磁盘才是真正存储数据的地方，否则一断电，数据在内存中，就消失了。

日志缓冲区保存了数据库相关操作的日志，记录了这个动作，然后由LGWR后台进程将其从日志缓冲区这个内存区写进磁盘的日志文件里，目的很简单，就是为了便于将来出现异常情况时，可以根据日志文件中记录的动作，在继续执行一遍，从而保护数据的安全。

举个简单的例子：新建好一个数据库，完成如下三个动作

1. A动作，建立一张表T

2. B动作，插入一条数据到T表

3. 将该数据更新某字段