译者:叶金荣(email:
),来源:mysql手册版本 5.0.20,转载请注明译者和出处,并且不能用于商业用途,违者必究。
![email.gif](https://i-blog.csdnimg.cn/blog_migrate/c3f7cf7250583b5dab147ec66529b7bd.gif)
7.2.2 估算查询性能
在大多数情况下,可以通过统计磁盘搜索次数来估算查询的性能。对小表来说,通常情况下只需要搜索一次磁盘就能找到对应的记录(因为索引可能已经缓存起来了)。对大表来说,大致可以这么估算,它使用b树做索引,想要找到一条记录大概需要搜索的次数为:
log(row_count) / log(index_block_length / 3 * 2 / (index_length + data_pointer_length)) + 1
。
在mysql中,一个索引块通常是1024bytes,数据指针通常是4bytes。对于一个有500,000条记录、索引长度为3bytes(medium integer)的表来说,根据上面的公式计算得到需要做
log(500,000)/log(1024/3*2/(3+4)) + 1
=
4
次搜索。
这个表的索引大概需要 500,000 * 7 * 3/2 = 5.2mb的存储空间(假定典型的索引缓冲区的2/3),因此应该会有更多的索引在内存中,并且可能只需要1到2次调用就能找到对应的记录。
对于写来说,大概需要4次(甚至更多)搜索才能找到新的索引位置,更新记录时通常需要2次搜索。
请注意,前面的讨论中并没有提到应用程序的性能会因为log n的值越大而下降。只要所有的东西都能由操作系统或者sql服务器缓存起来,那么性能只会因为数据表越大而稍微下降。当数据越来越大之后,就不能全部放到缓存中去了,就会越来越慢了,除非应用程序是被磁盘搜索约束的(它跟随着的log
n值增加而增加)。为了避免这种情况,可以在数据量增大以后也随着增大索引缓存容量。对
myisam
类型表来说,索引缓存容量是由系统变量
key_buffer_size
控制的。详情请看"
7.5.2 tuning server parameters"。
7.2.3 select
查询的速度
通常情况下,想要让一个比较慢的
以下是几个常用的提高
select ... where
查询变得更快的第一件事就是,先检查看看是否可以增加索引。所有对不同表的访问都通常使用索引。可以使用
explain
语句来判断
select
使用了哪些索引。详情请看"
7.4.5 how mysql uses indexes"和"
7.2.1 explain
syntax (get information about a select
)"。
myisam
表查询速度的忠告:
想要让mysql将查询优化的速度更快些,可以在数据表已经加载完全部数据后执行行
analyze table
或运行
myisamchk --analyze
命令。它更新了每个索引部分的值,这个值意味着相同记录的平均值(对于唯一索引来说,这个值则一直都是 1)。mysql就会在当你使用基于一个非恒量表达式的两表连接时,根据这个值来决定使用哪个索引。想要查看结果,可以在分析完数据表后运行
show index from tbl_name
查看
cardinality
字段的值。
myisamchk --description --verbose
显示了索引的分布信息。
想要根据一个索引来排序数据,可以运行
myisamchk --sort-index --sort-records=1
(如果想要在索引 1 上做排序)。这对于有一个唯一索引并且想根据这个索引的顺序依次读取记录的话来说是一个提高查询速度的好办法。不过要注意的是,第一次在一个大表上做排序的话将会耗费很长时间。
where 子句
这个章节讲述了优化程序如何处理
where
子句。例子中使用了
select
语句,但是在
delete
和
update
语句中对
where
子句的优化是一样的。
注意,关于mysql优化的工作还在继续,因此本章节还没结束。mysql做了很多优化工作,而不仅仅是文档中提到的这些。
mysql的一些优化做法如下:
去除不必要的括号:
((a and b) and c or (((a and b) and (c and d)))) -> (a and b and c) or (a and b and c and d)
展开常量:
(a<b and b=c) and a=5 -> b>5 and b=c and a=5
去除常量条件(在展开常量时需要):
(b>=5 and b=5) or (b=6 and 5=5) or (b=7 and 5=6) -> b=5 or b=6
常量表达示在索引中只计算一次
在单独一个表上做
以下的几个表都会被当成常量表: select * from t where primary_key=1; select * from t1,t2 where t1. primary_key=1 and t2. primary_key=t1.id; mysql会进各种可能找到表连接最好的连接方法。 如果在
count(*)
而不使用
where
时, 对于
myisam
和
heap
表就会直接从表信息中检索结果。在单独一个表上做任何表
not null
达式查询时也是这样做。
预先探测无效的常量表达式。mysql会快速探测一些不可能的
select
语句并且不返回任何记录。
当没用
group by
或分组函数时,
having
和
where
合并(
count()
,
min()
等也是如此)。
为表连接中的每个表构造一个简洁的
where
语句,以得到更快的
where
计算值并且尽快跳过记录。
查询中所有的常量表都会比其他表更早读取。一个常量表符合以下几个条件:
- 空表或者只有一条记录。
- 与在一个
unique
索引、或一个primary key
的where
子句一起使用的表,这里所有的索引部分和常数表达式做比较并且索引部分被定义为not null
。
以下的几个表都会被当成常量表: select * from t where primary_key=1; select * from t1,t2 where t1. primary_key=1 and t2. primary_key=t1.id; mysql会进各种可能找到表连接最好的连接方法。 如果在
order by
和
group by
子句中的所有字段都来自同一个表的话,那么在连接时这个表就会优先处理。
如果有
order by
子句和一个不同的
group by
子句,或者如果
order by
或
group by
中的字段都来自其他的表而非连接顺序中的第一个表的话,就会创建一个临时表了。
如果使用
sql_small_result
,mysql就会使用内存临时表了。
所有的表索引都会查询,最好的情况就是所有的索引都会被用到,除非优化程序认为全表扫描的效率更高。同时,数据表扫描是基于判断最好的索引范围超过数据表的30%。 现在,优化程序复杂多了,它基于对一些附加因素的估计,例如表大小,记录总数,i/o块大小,因此就不能根据一个固定的百分比来决定是选择使用索引还是直接扫描数据表。
在某些情况下,mysql可以直接从索引中取得记录而无需查询数据文件。如果所有在索引中使用的字段都是数字类型的话,只需要用索引树就能完成查询。
每条记录输出之前,那些没有匹配
having
子句的就会被跳过。
以下几个查询速度非常快: select count(*) from tbl_name; select min( key_part1),max( key_part1) from tbl_name; select max( key_part2) from tbl_name where key_part1= constant; select ... from tbl_name order by key_part1, key_part2,... limit 10; select ... from tbl_name order by key_part1 desc, key_part2 desc, ... limit 10;
以下几个查询都是使用索引树,假使那些索引字段都是数字型:
select
key_part1,
key_part2 from
tbl_name where
key_part1=
val; select count(*) from
tbl_name where
key_part1=
val1 and
key_part2=
val2; select
key_part2 from
tbl_name group by
key_part1;
以下几个查询使用索引来取得经过顺序排序后的记录而无需经过独立的排序步骤:
select ... from
tbl_name order by
key_part1,
key_part2,... ; select ... from
tbl_name order by
key_part1 desc,
key_part2 desc, ... ;
or 子句
index merge
方法用于使用
ref
,
ref_or_null
, 或
range
扫描取得的记录合并起来放到一起作为结果。这种方法在表条件是或条件
ref
,
ref_or_null
, 或
range
,并且这些条件可以用不同的键时采用。
"join"类型的优化是从 mysql 5.0.0 开始才有的,代表者在索引的性能上有着标志性的改进,因为使用老规则的话,数据库最多只能对每个引用表使用一个索引。
在
explain
的结果中,这种方法在
type
字段中表现为
index_merge
。这种情况下,
key
字段包含了所有使用的索引列表,并且
key_len
字段包含了使用的索引的最长索引部分列表。
例如: select * from tbl_name where key_part1 = 10 or key_part2 = 20; select * from tbl_name where ( key_part1 = 10 or key_part2 = 20) and non_key_part=30; select * from t1,t2 where (t1. key1 in (1,2) or t1. key2 like ' value%') and t2. key1=t1. some_col; select * from t1,t2 where t1. key1=1 and (t2. key1=t1. some_col or t2. key2=t1. some_col2);
is null
mysql在 col_name
is null
时做和
col_name
=
constant_value 一样的优化。例如,mysql使用索引或者范围来根据
is nul l
搜索
null
。
select * from
tbl_name where
key_col is null; select * from
tbl_name where
key_col <=> null; select * from
tbl_name where
key_col=
const1 or
key_col=
const2 or
key_col is null;
如果一个
where
子句包括了一个
col_name
is null
条件,并且这个字段声明为
not null
,那么这个表达式就会被优化。当字段可能无论如何都会产生
null
值时,就不会再做优化了;例如,当它来自一个
left join
中右边的一个表时。
mysql 4.1.1或更高会对连接
col_name = expr and col_name is null
做额外的优化, 常见的就是子查询。
explain
当优化起作用时会显示
ref_or_null
。
优化程序会为任何索引部分处理
以下几个例子中都做优化了,假使字段
is null
。
a
和 表
t2
中
b
有索引了:
select * from t1 where t1.a=
expr or t1.a is null; select * from t1,t2 where t1.a=t2.a or t2.a is null; select * from t1,t2 where (t1.a=t2.a or t2.a is null) and t2.b=t1.b; select * from t1,t2 where t1.a=t2.a and (t2.b=t1.b or t2.b is null); select * from t1,t2 where (t1.a=t2.a and t2.a is null and ...) or (t1.a=t2.a and t2.a is null and ...);
ref_or_null
首先读取引用键,然后独立扫描键值为
null
的记录。
is null
级别。下面的查询中,mysql只会使用键来查询表达式
(t1.a=t2.a and t2.a is null)
而无法使在
b
上使用索引部分:
select * from t1,t2 where (t1.a=t2.a and t2.a is null) or (t1.b=t2.b and t2.b is null);
distinct
在很多情况下,
distinct
和
order by
一起使用时就会创建一个临时表。
注意,由于
distinct
可能需要用到
group by
,就需要明白mysql在
order by
或
having
子句里的字段不在选中的字段列表中时是怎么处理的。详情请看"
13.9.3 group by
with hidden fields"。
当
如果没有用到来自查询中任何表的字段时,mysql在找到第一个匹配记录后就会停止搜索这些没没用到的表了。在下面的情况中,假使
limit row_count
和
distinct
一起使用时,mysql在找到
row_count 不同记录后就会立刻停止搜索了。
t1
在
t2
前就使用了(可以通过
explain
分析知道),mysql就会在从
t2
中找到第一条记录后就不再读
t2
了(为了能和中
t1
的任何特定记录匹配):
select distinct t1.a from t1,t2 where t1.a=t2.a;
left join 和 right join
a left join b join_condition
在mysql中实现如下:
表
b
依赖于表
a
以及其依赖的所有表。
表
a
依赖于在
left join
条件中的所有表(除了
b
)。
left join
条件用于决定如何从表
b
中读取记录了(换句话说,
where
子句中的任何条件都对此不起作用)。
所有标准的连接优化都会执行,例外的情况是有一个表总是在它依赖的所有表之后被读取。如果这是一个循环的依赖关系,那么mysql会认为这是错误的。
所有的标准
where
优化都会执行。
如果
a
中有一条记录匹配了
where
子句,但是
b
中没有任何记录匹配
on
条件,那么就会产生一条
b
记录,它的字段值全都被置为
null
。
如果使用
left join
来搜索在一些表中不存在的记录,并且
where
部分中有检测条件:
col_name is null
,
col_name
字段定义成
not null
的话,mysql就会在找到一条匹配
left join
条件的记录(用于和特定的索引键做联合)后停止搜索了。
right join
的实现和
left join
类似,不过表的角色倒过来了。
连接优化程序计算了表连接的次序。表读取的顺序是由
left join
强行指定的,而且使用
straight_join
能帮助连接优化程序更快地执行,因为这就会有更少的表排队检查了。注意,这里是指如果你执行下面这种类型的查询后,mysql就会对
b
做一次全表扫描,因为
left join
强制要求了必须在读
d
之前这么做:
select * from a,b left join c on (c.key=a.key) left join d on (d.key=a.key) where b.key=d.key;
解决这种情况的方法是按照如下方式重写查询:
select * from b,a left join c on (c.key=a.key) left join d on (d.key=a.key) where b.key=d.key;
从4.0.14开始,mysql做如下
例如,下面的查询中如果
select * from t1 left join t2 on (column1) where t2.column2=5;
left join
优化:如果对产生的
null
记录
where
条件总是
假
,那么
left join
就会变成一个普通的连接。
例如,下面的查询中如果
t2.column1
的值是
null
的话,
where
子句的结果就是
假
了:
因此,这就可以安全的转换成一个普通的连接查询:
select * from t1,t2 where t2.column2=5 and t1.column1=t2.column1;
这查询起来就更快了,因为如果能有一个更好的查询计划的话,mysql就会在
t1
之前就用到
t2
了。想要强行指定表顺序的话,可以使用
straight_join
。
转载于:https://blog.51cto.com/kiddymeet/5676