Heim  >  Artikel  >  Datenbank  >  MySQL的查询性能优化(1)

MySQL的查询性能优化(1)

WBOY
WBOYOriginal
2016-06-07 16:07:271104Durchsuche

使用EXPLAIN语句检查SQL语句 当你在一条SELECT语句前放上关键词EXPLAIN,MySQL解释它将如何处理SELECT,提供有关表如何联结和以什么次序联结的信息。 借助于EXPLAIN,你可以知道你什么时候必须为表加入索引以得到一个使用索引找到记录的更快的SELECT。 EXPLA


使用EXPLAIN语句检查SQL语句

当你在一条SELECT语句前放上关键词EXPLAIN,MySQL解释它将如何处理SELECT,提供有关表如何联结和以什么次序联结的信息。

借助于EXPLAIN,你可以知道你什么时候必须为表加入索引以得到一个使用索引找到记录的更快的SELECT。

EXPLAIN tbl_name

or  EXPLAIN SELECT select_options
EXPLAIN tbl_name
DESCRIBE tbl_name或SHOW COLUMNS FROM tbl_name的一个同义词。

从EXPLAIN的输出包括下面列:

·table
输出的行所引用的表。

· type
联结类型。各种类型的信息在下面给出。
不同的联结类型列在下面,以最好到最差类型的次序:
system const eq_ref ref range index ALL possible_keys

· key
key列显示MySQL实际决定使用的键。如果没有索引被选择,键是NULL。

· key_len
key_len列显示MySQL决定使用的键长度。如果键是NULL,长度是NULL。注意这告诉我们MySQL将实际使用一个多部键值的几个部分。

· ref
ref列显示哪个列或常数与key一起用于从表中选择行。

· rows
rows列显示MySQL相信它必须检验以执行查询的行数。

·Extra
如果Extra列包括文字Only index,这意味着信息只用索引树中的信息检索出的。通常,这比扫描整个表要快。如果Extra列包括文字where used,它意味着一个WHERE子句将被用来限制哪些行与下一个表匹配或发向客户。
通过相乘EXPLAIN输出的rows行的所有值,你能得到一个关于一个联结要多好的提示。这应该粗略地告诉你MySQL必须检验多少行以执行查询。

例如,下面一个全连接:

mysql> EXPLAIN SELECT student.name From student,pet
-> WHERE student.name=pet.owner;

其结论为:
+---------+------+---------------+------+---------+------+------+------------+
| table   | type | possible_keys | key  | key_len | ref  | rows | Extra      |
+---------+------+---------------+------+---------+------+------+------------+
| student | ALL  | NULL          | NULL |    NULL | NULL |   13 |            |
| pet     | ALL  | NULL          | NULL |    NULL | NULL |    9 | where used |
+---------+------+---------------+------+---------+------+------+------------+

SELECT 查询的速度

总的来说,当你想要使一个较慢的SELECT ... WHERE更快,检查的第一件事情是你是否能增加一个索引。在不同表之间的所有引用通常应该用索引完成。你可以使用EXPLAIN来确定哪个索引用于一条SELECT语句。

一些一般的建议:
·为了帮助MySQL更好地优化查询,在它已经装载了相关数据后,在一个表上运行myisamchk --analyze。这为每一个更新一个值,指出有相同值地平均行数(当然,对唯一索引,这总是1。)
·为了根据一个索引排序一个索引和数据,使用myisamchk --sort-index --sort-records=1(如果你想要在索引1上排序)。如果你有一个唯一索引,你想要根据该索引地次序读取所有的记录,这是使它更快的一个好方法。然而注意,这个排序没有被最佳地编写,并且对一个大表将花很长时间!

MySQL怎样优化WHERE子句

where优化被放在SELECT中,因为他们最主要在那里使用里,但是同样的优化被用于DELETE和UPDATE语句。

也要注意,本节是不完全的。MySQL确实作了许多优化而我们没有时间全部记录他们。

由MySQL实施的一些优化列在下面:

1、删除不必要的括号:
((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)

2、常数调入:
(a-> b>5 AND b=c AND a=5

3、删除常数条件(因常数调入所需):
(B>=5 AND B=5) OR (B=6 AND 5=5) OR (B=7 AND 5=6)
-> B=5 OR B=6

4、索引使用的常数表达式仅计算一次。

5、在一个单个表上的没有一个WHERE的COUNT(*)直接从表中检索信息。当仅使用一个表时,对任何NOT NULL表达式也这样做。

6、无效常数表达式的早期检测。MySQL快速检测某些SELECT语句是不可能的并且不返回行。

7、如果你不使用GROUP BY或分组函数(COUNT()、MIN()……),HAVING与WHERE合并。

8、为每个子联结(sub join),构造一个更简单的WHERE以得到一个更快的WHERE计算并且也尽快跳过记录。

9、所有常数的表在查询中的任何其他表前被首先读出。一个常数的表是:

·一个空表或一个有1行的表。

·与在一个UNIQUE索引、或一个PRIMARY KEY的WHERE子句一起使用的表,这里所有的索引部分使用一个常数表达式并且索引部分被定义为NOT NULL。

所有下列的表用作常数表

mysql> SELECT * FROM t WHERE primary_key=1;
mysql> SELECT * FROM t1,t2
WHERE t1.primary_key=1 AND t2.primary_key=t1.id;

10、对联结表的最好联结组合是通过尝试所有可能性来找到:(。如果所有在ORDER BY和GROUP BY的列来自同一个表,那么当廉洁时,该表首先被选中。

11、如果有一个ORDER BY子句和一个不同的GROUP BY子句,或如果ORDER BY或GROUP BY包含不是来自联结队列中的第一个表的其他表的列,创建一个临时表。

12、如果你使用SQL_SMALL_RESULT,MySQL将使用一个在内存中的表。

13、因为DISTINCT被变换到在所有的列上的一个GROUP BY,DISTINCT与ORDER BY结合也将在许多情况下需要一张临时表。

14、每个表的索引被查询并且使用跨越少于30% 的行的索引。如果这样的索引没能找到,使用一个快速的表扫描。

15、在一些情况下,MySQL能从索引中读出行,甚至不咨询数据文件。如果索引使用的所有列是数字的,那么只有索引树被用来解答查询。

16、在每个记录被输出前,那些不匹配HAVING子句的行被跳过。

下面是一些很快的查询例子

mysql> SELECT COUNT(*) FROM tbl_name;
mysql> SELECT MIN(key_part1),MAX(key_part1) FROM tbl_name;
mysql> SELECT MAX(key_part2) FROM tbl_name
           WHERE key_part_1=constant;
mysql> SELECT ... FROM tbl_name
           ORDER BY key_part1,key_part2,... LIMIT 10;
mysql> SELECT ... FROM tbl_name
           ORDER BY key_part1 DESC,key_part2 DESC,... LIMIT 10;

下列查询仅使用索引树就可解决(假设索引列是数字的):

mysql> SELECT key_part1,key_part2 FROM tbl_name WHERE key_part1=val;
mysql> SELECT COUNT(*) FROM tbl_name
           WHERE key_part1=val1 AND key_part2=val2;
mysql> SELECT key_part2 FROM tbl_name GROUP BY key_part1;

下列查询使用索引以排序顺序检索,不用一次另外的排序:

mysql> SELECT ... FROM tbl_name ORDER BY key_part1,key_part2,...
mysql> SELECT ... FROM tbl_name ORDER BY key_part1 DESC,key_part2 DESC,...

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn