Atitit Mysql查询优化器 存取类型 范围存取类型 索引存取类型 AND or的分析

Atitit Mysql查询优化器 存取类型 范围存取类型 索引存取类型 AND or的分析

 

 

Atitit Mysql查询优化器 存取类型 范围存取类型 索引存取类型 AND or的分析1

存取类型1

5         范围存取类型2

6         索引存取类型2

7         转换3

AND3

9         OR3

10    UNION3

11    NOT,<>4

12    ORDER BY4

13    GROUP BY4

存取类型

当我们评估一个条件表达式，MySQL判断该表达式的存取类型。下面是一些存取类型，按照从最优到最差的顺序进行排列：

system系统表，并且是常量表

const  常量表

eq_ref  unique/primary索引，并且使用的是'='进行存取

ref  索引使用'='进行存取

ref_or_null  索引使用'='进行存取，并且有可能为NULL

range  索引使用BETWEEN、IN、>=、LIKE等进行存取

index  索引全扫描

ALL  表全扫描

优化器根据存取类型选择合适的驱动表达式。考虑如下的查询语句：以下是引用片段：

　SELECT *FROM Table1  WHERE indexed_column=5 AND  unindexed_column=6

因为indexed_column拥有更好的存取类型，所以更有可能使用该表达式做为驱动表达式。这里只考虑简单的情况，不考虑特殊的情况。那么驱动表达式的意思是什么呢?考虑到这个查询语句有两种可能的执行方法:

1) 不好的执行路径：读取表的每一行(称为“全表扫描”)，对于读取到的每一行，检查相应的值是否满足indexed_column以及 unindexed_column对应的条件。

2) 好的执行路径：通过键值indexed_column=5查找B树，对于符合该条件的每一行，判断是否满足unindexed_column对应的条件。

一般情况下，索引查找比全表扫描需要更少的存取路径，尤其当表数据量很大，并且索引的类型是UNIQUE的时候。因此称它为好的执行路径，使用 indexed_column列作为驱动表达式。

5         范围存取类型

一些表达式可以使用索引，但是属于索引的范围查找。这些表达式通常对应的操作符是：>、>=、<、<=、IN、LIKE、 BETWEEN。

　　对优化器而言，如下表达式：

column1 IN (1,2,3)

　　该表达式与下面的表达式是等价的：

column1 = 1 OR column1 = 2 OR column1 = 3

　　并且 MySQL也是认为它们是等价的，所以没必要手动将IN改成OR,或者把OR改成IN。

　　优化器将会对下面的表达式使用索引范围查找：column1 LIKE 'x%'，但对下面的表达式就不会使用到索引了：column1 LIKE '%x'，这是因为当首字符是通配符的时候， 没办法使用到索引进行范围查找。

　　对优化器而言，如下表达式：column1 BETWEEN 5 AND 7　该表达式与下面的表达式是等价的：column1 >= 5 AND column1 <= 7同样，MySQL也认为它们是等价的。

　　如果需要检查过多的索引键值，优化器将放弃使用索引范围查找，而是使用全表扫描的方式。这样的情况经常出现如下的情况下：索引是多层次的二级索引，查询条件是'<'以及是'>'的情况。

6         索引存取类型

考虑如下的查询语句：SELECT column1 FROM Table1;如果column1是索引列， 优化器更有可能选择索引全扫描，而不是采用表全扫描。这是因为该索引覆盖了我们所需要查询的列。　再考虑如下的查询语句：　SELECT column1,column2 FROM Table1;　　如果索引的定义如下，那么就可以使用索引全扫描：CREATE INDEX … ON Table1(column1,column2);　　也就是说，所有需要查询的列必须在索引中出现。但是如下的查询就只能走全表扫描了： select col3 from Table1;由于col3没有建立索引所以只能走全表扫描。由此其实我们的Cn表中建立的索引其实还是有一些问题的：

PRIMARY KEY  (`CID`),

UNIQUE KEY `IDX_CN_CNAME` (`CNAME`),

KEY `INDEX_CN_CID_UID` (`CID`,`CUSTOMERID`),

KEY `INDEX_CN_PRODTYPE` (`PRODTYPE`),

KEY `INDEX_CN_P_C` (`PRODTYPE`,`CNSTATUS`),

KEY `INDEX_CN_UID` (`CUSTOMERID`)

比如所cid是唯一索引，由cid已经能唯一确定一条记录，那么在以cid和customerid建立索引实际上是多余的。同样，建立了prodtype和cnstatus的复合索引，再建立prodtype的索引也是有问题的，即使你使用了prodtype字段作为条件查询，也未必就会使用prodtype的索引，因为他们有着相同的前缀，故优化器根本搞不清楚你要使用哪个索引，所以，尽量避免相同的前缀的索引。

7         转换

MySQL对简单的表达式支持转换。比如下面的语法：WHERE -5 = column1转换为：　 　WHERE column1 = -5　尽管如此，对于有数学运算存在的情况不会进行转换。比如下面的语法：　WHERE 5 = -column1不会转换为：WHERE column1 = -5，所以尽量减少列上的运算，而将运算放到常量上。比如我们在写sql的时候自觉的将5= -columb1=> column1=-5;

AND

带AND的查询的格式为： AND ，考虑如下的查询语句：

WHERE column1='x' AND column2='y'

优化的步骤：

1) 如果两个列都没有索引，那么使用全表扫描。

2) 否则，如果其中一个列拥有更好的存取类型(比如，一个具有索引，另外一个没有索引;再或者，一个是唯一索引，另外一个是非唯一索引)，那么使用该列作为驱动表达式。

3) 否则，如果两个列都分别拥有索引，并且两个条件对应的存取类型是一致的，那么选择定义索引时,先定义的索引。

　举例如下：

CREATE TABLE Table1 (s1 INT,s2 INT);

CREATE INDEX Index1 ON Table1(s2);

CREATE INDEX Index2 ON Table1(s1);

　…

SELECT * FROM Table1 WHERE s1=5 AND s2=5;

　　优化器选择s2=5作为驱动表达式，因为s2上的索引是创建的时间早。

9         OR

带OR的查询格式为： OR ，考虑如下的查询语句：WHERE column1='x' OR column2='y'

优化器做出的选择是采用全表扫描。当然，在一些特定的情况，可以使用索引合并，这里不做阐述。如果两个条件里面设计的列是同一列，那么又是另外一种情况，考虑如下的查询语句：WHERE column1='x' OR column1='y'在这种情况下，该查询语句采用索引范围查找。

10    UNION

所有带UNION的查询语句都是单独优化的，考虑如下的查询语句：以下是引用片段：　　SELECT * FROM  Table1   WHERE  column1='x'

UNIONALL SELECT * FROM Table1  WHER  column2='y'

如果column1与column2都是拥有索引 的，每个查询都是使用索引查询，然后合并结果集。

11    NOT,<>

考虑如下的表达式：　Column1<> 5从逻辑上讲，该表达式等价于下面的表达式：

Column1<5 OR column1>5　然而，MySQL不会进行这样的转换。如果你觉得使用范围查找会更好一些，应该手动地进行转换。

　　考虑如下的表达式：　WHERE NOT (column1!=5) 从逻辑上讲，该表达式等价于下面的表达式：WHERE column1=5　同样地，MySQL也不会进行这样的转换。

12    ORDER BY

一般而言，ORDER BY的作用是使结果集按照一定的顺序排序，如果可以不经过此操作就能产生顺序的结果，可以跳过该ORDER BY操作。考虑如下的查询 语句：

SELECT column1 FROM Table1 ORDER BY 'x';优化器将去除该 ORDER BY子句，因为此处的ORDER BY子句没有意义。再考虑另外的一个查询语句：SELECT column1 FROM Table1 ORDER BY column1;

在这种情况下，如果column1类上存在索引，优化器将使用该索引进行全扫描，这样产生的结果集是有序的，从而不需要进行ORDER BY操作。

再考虑另外的一个查询语句：SELECT column1 FROM Table1 ORDER BY column1+1;　　假设column1上存在索引，我 们也许会觉得优化器会对column1索引进行全扫描，并且不进行ORDER BY操作。实际上，情况并不是这样，优化器是使用column1列上的索引进行全扫表，仅仅是因为索引全扫描的效率高于表全扫描。对于索引全扫描的结果集 仍然进行ORDER BY排序操作。

13    GROUP BY

这里列出对GROUP BY子句以及相关集函数进行优化的方法：

1)      如果存在索引，GROUP BY将使用索引。

2) 如果没有索引，优化器将需要进行排序，一般情况下会使用HASH表的方法。

3) 如果情况类似于“GROUP BY x ORDER BY x”,优化器将会发现ORDER BY子句是没有必要的，因为GROUP BY产生的结果集是按照x进行排序的。

4) 尽量将HAVING子句中的条件提升中WHERE子句中。

5) 对于MyISAM表，“SELECT COUNT(*) FROM Table1;”直接返回结果，而不需要进行表全扫描。但是对于InnoDB表，则不适合该规则。补充一点，如果column1的定义是NOT NULL的，那么语句“SELECT COUNT(column1) FROM Table1;”等价于“SELECT COUNT(*) FROM Table1;”。

6) 考虑MAX()以及MIN()的优化情况。考虑下面的查询语句：以下是引用片段：
 　SELECTMAX(column1)FROMTable1WHEREcolumn1<'a'; 　如果column1列上存在索引，优化器使用'a'进行索引定位，然后返回前一条记录。

7) 考虑如下的查询语句:

SELECT DISTINCT column1 FROM Table1;在特定的情况下，语句可以转化为：

SELECT column1 FROM Table1 GROUP BY column1;转换的前提条件是：column1上存 在索引，FROM上只有一个单表，没有WHERE条件并且没有LIMIT条件。

作者:: 绰号:老哇的爪子claw of Eagle 偶像破坏者Iconoclast image-smasher

捕鸟王"Bird Catcher 王中之王King of Kings 虔诚者Pious 宗教信仰捍卫者 Defender of the Faith. 卡拉卡拉红斗篷 Caracalla red cloak

简称：： Emir Attilax Akbar 埃米尔 阿提拉克斯 阿克巴

全名：：Emir Attilax Akbar bin Mahmud bin  attila bin Solomon Al Rapanui

埃米尔 阿提拉克斯 阿克巴 本 马哈茂德 本 阿提拉 本 所罗门  阿尔 拉帕努伊

常用名：艾提拉（艾龙），   EMAIL:1466519819@qq.com

转载请注明来源：attilax的专栏   http://www.cnblogs.com/attilax/

--Atiend