<Oracle优化新常态>第一章

<Oracle优化新常态>第二章强拆（1）

<Oracle优化新常态>第二章强拆（2）

<Oracle优化新常态> 第三章 三大配置

<Oracle优化新常态>第四章 分库分表

<Oracle优化新常态> 第五章 急诊法

<Oracle优化新常态> 第六章 SQL优化大法

<Oracle优化新常态> 第七章 五大禁止

在第六章中 SQL优化大法 落掉一法 就是 标量查询消除法。

所谓标量查询是指在SELECT 字段中套了个子查询，比如如下

select a.name,

(select b.age from b inner join a on a.id=b.id where b.scoe=90) as age

from a

因为标量查询会对每返回一行的数据做一次查询，标量查询如同函数一般的行为。很显然FROM A 如果有1亿人的话，基本上就要做1亿次 查询工作。

WHO-IT 方法

W （Waite Event）是等待事件

H （Hit rate） 是命中率

O (thrOughput）吞吐量

I (Inetractive） 交互式

T (Reponse Time) 响应时间

虽然如今Waite Event 等待事件很热门，从2005年热到现在，也没啥发展了！

ORACLE数据库优化除了优化SQL外，自然需要一套优化的方法。开始的时候7i和8i讲究的是优化命中率，就是各个缓存区的是使用效率的问题。虽然如今的等待事件被各位DBA放在嘴上津津乐道，当是并非命中率就没有用武之地了。

如果各个缓存池的命中率都比较低，低于90，是不是存在大量的问题呢？需要提高命中率来提高整个数据库的运行性能。

吞吐量：一个数据库服务器大家都知道有个IO的吞吐量，叫MBPS。另外还有个IOPS。而这里的吞吐量是指整个数据库系统。包含了内存,CPU已经ORACLE对象的锁资源。好比是一名员工的，在考核其工作任务是否繁重？是否达到了该员工的工作上限了？ 因此需要量化该员工的工作能力。

为此我们也是要压力测试数据库的上限值，一档任务量达到了一个阈值，那么数据库就出现了崩溃的迹象，也就是量化积累到一定程度后达到了质化的线。

此工作压力，不仅仅是单项工作任务的量上的增长，还指多项工作任务增加。

等待事件：是指完成了某个环节，在进入下个环节工作的时候，在等待条件的准备。比如说CPU在等待数据读入到内存中，这个等待过程就算做一个事件。

响应时间：这个是从用户角度来说，用户感觉快慢指的是时间尽量的短。从用户这里引申出对数据库内部所有都可以用时间来量化。DB TIME是我们常见的时间，这个时间是所有CPU内核工作的时间。等待事件也有时间叫等待时间。那么响应时间=工作时间+等待时间。自然工作时间和等待时间还可以细分。

交互式：这个是从应用角度来看，在BS架构中一个业务，一个页面，一个按钮它们的动作将会产生多少个SQL发给后端的数据库执行？ 如果DBA不懂业务的话，自然无法优化业务，如果不懂JAVA的话，自然无法优化页面，如果不懂JAVA开发工具用来调试的话，自然不懂按钮的优化。

什么意思呢？ 这样说吧！ 一个按钮按下去，将执行1-N多个SQL 。那么你不懂的JAVA工具的话，就无法抓住这一些SQL。 而平时是在数据库角度来看每个SQL，查出最慢的SQL。而数据库看到慢的SQL不一定是按钮发出来的SQL。或许你说通过SESSION就能抓到，可惜的是应用程序使用的链接池，每个SQL会使用不同的链接线路，自然就分布在不同的SESSION中。

按钮和按钮之间 是否有重复的SQL呢？ 比如说一个分页呈现出数据来，一个NEXT按钮。而这个NEXT按钮 执行的是重新查询所有的数据，然后在现在第2页呈现出来。

所以 SQL 与SQL 之间是有前后顺序的，这一串我们需要把它给抓起来的。

我们DBA 干到 页面内按钮与按钮之间是否有重复的，就非常不错了！

至于业务 小仙我想说懂些好装逼，与高层有沟通的语言！ 剩下的只能踢给JAVA开发人员去优化吧！

为此我们需要建立一个表格，把SQL 关联到页面，按钮。这样下来我们就知道一个页面下有多少个SQL，一个按钮执行了多少SQL，前后顺序。自然反推也知道哪个SQL来自于哪个页面，哪个按钮。

page_id,page_name,page_wrl;

buttion_id,buttion_name

sql_Id,sql_text