大家好,欢迎来到IT知识分享网。
Mysql
查询优化器浅析(下)
查询优化器浅析(下)
译者:杨万富
7
存取类型
存取类型
当我们评估一个条件表达式,
MySQL
判断该表达式的存取类型。下面是一些存取类型,按照从最优到最差的顺序进行排列:
system …
系统表,并且是常量表
系统表,并且是常量表
const …
常量表
常量表
eq_ref … unique/primary
索引,并且使用的是
‘=’
进行存取
索引,并且使用的是
‘=’
进行存取
ref …
索引使用
‘=’
进行存取
索引使用
‘=’
进行存取
ref_or_null …
索引使用
‘=’
进行存取,并且有可能为
NULL
索引使用
‘=’
进行存取,并且有可能为
NULL
range …
索引使用
BETWEEN
、
IN
、
>=
、
LIKE
等进行存取
索引使用
BETWEEN
、
IN
、
>=
、
LIKE
等进行存取
index …
索引全扫描
索引全扫描
ALL …
表全扫描
表全扫描
优化器根据存取类型选择合适的驱动表达式。考虑如下的查询语句:
SELECT *
FROM Table1
WHERE indexed_column = 5 AND unindexed_column = 6
因为
indexed_column
拥有更好的存取类型,所以更有可能使用该表达式做为驱动表达式。这里只考虑简单的情况,不考虑特殊的情况。
那么驱动表达式的意思是什么呢?考虑到这个查询语句有两种可能的执行方法
:
1)
不好的执行路径:读取表的每一行(称为“全表扫描”),对于读取到的每一行,检查相应的值是否满足
indexed_column
以及
unindexed_column
对应的条件。
不好的执行路径:读取表的每一行(称为“全表扫描”),对于读取到的每一行,检查相应的值是否满足
indexed_column
以及
unindexed_column
对应的条件。
2)
好的执行路径:通过键值
indexed_column=5
查找
B
树,对于符合该条件的每一行,判断是否满足
unindexed_column
对应的条件。
好的执行路径:通过键值
indexed_column=5
查找
B
树,对于符合该条件的每一行,判断是否满足
unindexed_column
对应的条件。
一般情况下,索引查找比全表扫描需要更少的存取路径,尤其当表数据量很大,并且索引的类型是
UNIQUE
的时候。因此称它为好的执行路径,使用
indexed_column
列作为驱动表达式。
8
范围存取类型
范围存取类型
一些表达式可以使用索引,但是属于索引的范围查找。这些表达式通常对应的操作符是:
>
、
>=
、
<
、
<=
、
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
也认为它们是等价的。
如果需要检查过多的索引键值,优化器将放弃使用索引范围查找,而是使用全表扫描的方式。这样的情况经常出现如下的情况下:索引是多层次的二级索引,查询条件是
‘<‘
以及是
‘>’
的情况。
9
索引存取类型
索引存取类型
考虑如下的查询语句:
SELECT column1 FROM Table1;
如果
column1
是索引列,优化器更有可能选择索引全扫描,而不是采用表全扫描。这是因为该索引覆盖了我们所需要查询的列。
再考虑如下的查询语句:
SELECT column1,column2 FROM Table1;
如果索引的定义如下,那么就可以使用索引全扫描:
CREATE INDEX … ON Table1(column1,column2);
也就是说,所有需要查询的列必须在索引中出现。
10
转换
转换
MySQL
对简单的表达式支持转换。比如下面的语法:
对简单的表达式支持转换。比如下面的语法:
WHERE -5 = column1
转换为:
WHERE column1 = -5
尽管如此,对于有数学运算存在的情况不会进行转换。比如下面的语法:
WHERE 5 = -column1
不会转换为:
WHERE column1 = -5
11 AND
带
AND
的查询的格式为:
<condition> AND <condition>
,考虑如下的查询语句:
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
上的索引是新建的。
12 OR
带
OR
的查询格式为:
<condition> OR <condition>
,考虑如下的查询语句:
WHERE column1=’x’ OR column2=’y’
优化器做出的选择是采用全表扫描。
当然,在一些特定的情况,可以使用索引合并,这里不做阐述。
如果两个条件里面设计的列是同一列,那么又是另外一种情况,考虑如下的查询语句:
WHERE column1=’x’ OR column1=’y’
在这种情况下,该查询语句采用索引范围查找。
13 UNION
所有带
UNION
的查询语句都是单独优化的,考虑如下的查询语句:
SELECT * FROM Table1 WHERE column1=’x’
UNION ALL
SELECT * FROM Table1 WHERE column2=’y’
如果
column1
与
column2
都是拥有索引的,每个查询都是使用索引查询,然后合并结果集。
14 NOT,<>
考虑如下的表达式:
Column1<> 5
从逻辑上讲,该表达式等价于下面的表达式:
Column1<5 OR column1>5
然而,
MySQL
不会进行这样的转换。如果你觉得使用范围查找会更好一些,应该手动地进行转换。
考虑如下的表达式:
WHERE NOT (column1!=5)
从逻辑上讲,该表达式等价于下面的表达式:
WHERE column1=5
同样地,
MySQL
也不会进行这样的转换。
15 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
排序操作。
16 GROUP BY
这里列出对
GROUP BY
子句以及相关集函数进行优化的方法:
1)
如果存在索引,
GROUP BY
将使用索引。
如果存在索引,
GROUP BY
将使用索引。
2)
如果没有索引,优化器将需要进行排序,一般情况下会使用
HASH
表的方法。
如果没有索引,优化器将需要进行排序,一般情况下会使用
HASH
表的方法。
3)
如果情况类似于“
GROUP BY x ORDER BY x”,
优化器将会发现
ORDER BY
子句是没有必要的,因为
GROUP BY
产生的结果集是按照
x
进行排序的。
如果情况类似于“
GROUP BY x ORDER BY x”,
优化器将会发现
ORDER BY
子句是没有必要的,因为
GROUP BY
产生的结果集是按照
x
进行排序的。
4)
尽量将
HAVING
子句中的条件提升中
WHERE
子句中。
尽量将
HAVING
子句中的条件提升中
WHERE
子句中。
5)
对于
MyISAM
表,“
SELECT COUNT(*) FROM Table1;
”直接返回结果,而不需要进行表全扫描。但是对于
InnoDB
表,则不适合该规则。补充一点,如果
column1
的定义是
NOT NULL
的,那么语句“
SELECT COUNT(column1) FROM Table1;
”等价于“
SELECT COUNT(*) FROM Table1;
”。
对于
MyISAM
表,“
SELECT COUNT(*) FROM Table1;
”直接返回结果,而不需要进行表全扫描。但是对于
InnoDB
表,则不适合该规则。补充一点,如果
column1
的定义是
NOT NULL
的,那么语句“
SELECT COUNT(column1) FROM Table1;
”等价于“
SELECT COUNT(*) FROM Table1;
”。
6)
考虑
MAX()
以及
MIN()
的优化情况。考虑下面的查询语句:
考虑
MAX()
以及
MIN()
的优化情况。考虑下面的查询语句:
SELECT MAX(column1)
FROM Table1
WHERE column1 < ‘a’;
如果
column1
列上存在索引,优化器使用
‘a’
进行索引定位,然后返回前一条记录。
7)
考虑如下的查询语句
:
考虑如下的查询语句
:
SELECT DISTINCT column1 FROM Table1;
在特定的情况下,语句可以转化为:
SELECT column1 FROM Table1 GROUP BY column1;
该转换的前提条件是:
column1
上存在索引,
FROM
上只有一个单表,没有
WHERE
条件并且没有
LIMIT
条件。
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/24088.html