MYSQL网页编程之说一说Oracle的优化器(Optimizer)

由于在MySQL中有如此众多的额外功能可选，诸如存储引擎等，你可以选择最适合你公司的一个，或者尝试选用多个引擎。MySQL开始非常小巧，但是可以随着公司的成长而不断地变强大。oracle|优化
本文的目标：
1、说一说Oracle的Optimizer及其相干的一些常识。
2、回覆一下为何偶然一个表的某个字段明显有索引,当察看一些SQL的实行企图时,发明确不走索引的成绩。
3、假如你对FIRST_ROWS、ALL_ROWS这两种形式有困惑时也能够看一下这篇文章。

入手下手吧:


Oracle在实行一个SQL之前,起首要剖析一下语句的实行企图,然后再按实行企图往实行。剖析语句的实行企图的事情是由优化器(Optimizer)来完成的。分歧的情形,一条SQL大概有多种实行企图,但在某一时点,必定只要一种实行企图是最优的,消费工夫是起码的。信任你必定会用Pl/sqlDeveloper、Toad等工具往看一个语句的实行企图,不外你大概对Rule、Choose、Firstrows、Allrows这几项有疑问,由于我现在也是如许的,当时我也困惑为何选了以上的分歧的项,实行企图就变了?

1、优化器的优化体例

Oracle的优化器共有两种的优化体例,即基于划定规矩的优化体例(Rule-BasedOptimization,简称为RBO)和基于价值的优化体例(Cost-BasedOptimization,简称为CBO)。
A、RBO体例：优化器在剖析SQL语句时,所遵守的是Oracle外部预定的一些划定规矩。好比我们罕见的,当一个where子句中的一列有索引时往走索引。
B、CBO体例：依词义可知,它是看语句的价值(Cost)了,这里的价值次要指Cpu和内存。优化器在判别是不是用这类体例时,次要参照的是表及索引的统计信息。统计信息给出表的巨细、有少行、每行的长度等信息。这些统计信息后来在库内是没有的,是你在做analyze后才呈现的,良多的时侯过时统计信息会令优化器做出一个毛病的实行企图,因些我们应实时更新这些信息。在Oracle8及今后的版本,Oracle列保举用CBO的体例。

我们要了然,纷歧定走索引就是优的,好比一个表只要两行数据,一次IO就能够完玉成表的检索,而此时走索引时则必要两次IO,这时候对这个表做全表扫描(fulltablescan)是最好的。

2、优化器的优化形式(OptermizerMode)

优化形式包含Rule,Choose,Firstrows,Allrows这四种体例,也就是我们以上所说起的。以下我注释一下：

Rule:不必多说,即走基于划定规矩的体例。

Choolse:这是我们应不雅注的,默许的情形下Oracle用的即是这类体例。指的是当一个表或或索引有统计信息,则走CBO的体例,假如表或索引没统计信息,表又不是出格的小,并且响应的列有索引时,那末就走索引,走RBO的体例。

FirstRows:它与Choose体例是相似的,所分歧的是当一个表有统计信息时,它将是以最快的体例前往查询的开始的几行,从整体上削减了呼应工夫。

AllRows:也就是我们所说的Cost的体例,当一个表有统计信息时,它将以最快的体例前往表的一切的行,从整体上进步查询的吞吐量。没有统计信息则走基于划定规矩的体例。

3、怎样设定选用哪一种优化形式

a、Instance级别

我们能够经由过程在init<SID>.ora文件中设定OPTIMIZER_MODE=RULE、OPTIMIZER_MODE=CHOOSE、OPTIMIZER_MODE=FIRST_ROWS、OPTIMIZER_MODE=ALL_ROWS往选用3所提的四种体例,假如你没设定OPTIMIZER_MODE参数则默许用的是Choose这类体例。

B、Sessions级别

经由过程SQL>ALTERSESSIONSETOPTIMIZER_MODE=<Mode>;来设定。

C、语句级别

这些必要用到Hint,好比:
SQL>SELECT/*+RULE*/a.userid,
2b.name,
3b.depart_name
4FROMtf_f_yhdaa,
5tf_f_departb
6WHEREa.userid=b.userid;

4、为何偶然一个表的某个字段明显有索引,当察看一些语的实行企图确不走索引呢？怎样办理呢？

A、不走索引大致有以下几个缘故原由
♀你在Instance级别所用的是all_rows的体例
♀你的表的统计信息(最大概的缘故原由)
♀你的表很小,上文提到过的,Oracle的优化器以为不值得走索引。
B、办理办法
♀能够修正init<SID>.ora中的OPTIMIZER_MODE这个参数,把它改成Rule或Choose,重起数据库。也能够利用4中所提的Hint.
♀删除统计信息
SQL>analyzetabletable_namedeletestatistics;
♀表小不走索引是对的,不必调的。

5、别的相干

A、怎样看一个表或索引是不是是统计信息

SQL>SELECT*FROMuser_tables
2WHEREtable_name=<table_name>
3ANDnum_rowsisnotnull;

SQL>SELECT*FROMuser_indexes
2WHEREtable_name=<table_name>
3ANDnum_rowsisnotnull;

b、假如我们先用CBO的体例,我们应实时往更新表和索引的统计信息,以避免生形不符合实的实行企图。

SQL>ANALYZETABLEtable_nameCOMPUTESTATISTICS;
SQL>ANALYZEINDEXindex_nameESTIMATESTATISTICS;

详细的ANALYZE语句请参照Oracle8i/9i的refrence文档。

(全文完)


无疑希望员工得到系统、有深度的培训，显然MySQL在这一点上还做得很不够。

这是一个不错的新特性。虽然索引的附加字段没有索引键值效率高，但是相对映射到数据表中效率还是提高了很多。我做过试验，在我的实验环境中会比映射到表中提高30%左右的效率。

但是随着数据量的增大，这种成本差距会逐渐减小，趋于相等。（500万数量级只相差10%左右）

现在是在考虑:如果写到服务器端,我一下搞他个10个存储过程导过去,那久之服务器不就成垃圾箱了吗?即便优化了我的中间层.

始终遗憾SQLServer的登陆无法分配CPU/内存占用等指标数。如果你的SQLServer给别人分配了一个只可以读几个表的权限，而这个家伙疯狂的死循环进行连接查询，会给你的系统带来很大的负担。

一直以来个人感觉SQLServer的优化器要比Oracle的聪明。SQL2005的更是比2k聪明了不少。（有次作试验发现有的语句在200万级时还比50万级的相同语句要快show_text的一些提示没有找到解释。一直在奇怪。）

而SQLServer如果能像Oracle一样可以为登陆分配如：5%的cpu，10%的内存。就可以解决这个漏洞。