日期：2012-07-30 15:19:00 来源：本站整理
MySQL Order By索引优化办法[MySQL防范]
本文“MySQL Order By索引优化办法[MySQL防范]”是由七道奇为您精心收集，来源于网络转载，文章版权归文章作者所有，本站不对其观点以及内容做任何评价，请读者自行判断，以下是其具体内容：
固然 ORDER BY 不是和索引的次序精确匹配,索引还是可以被用到,只要不用的索引部份和全部的额外的 ORDER BY 字段在 WHERE 子句中都被包含了.
利用索引的MySQL Order By
下列的几个查询城市利用索引来办理 ORDER BY 或 GROUP BY 部份:
复制代码 代码以下:
SELECT * FROM t1 ORDER BY key_part1,key_part2,... ;
SELECT * FROM t1 WHERE key_part1=constant ORDER BY key_part2;
SELECT * FROM t1 WHERE key_part1=constant GROUP BY key_part2;
SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 DESC;
SELECT * FROM t1 WHERE key_part1=1 ORDER BY key_part1 DESC, key_part2 DESC;
不利用索引的MySQL Order By
在另一些情形下,MySQL无法利用索引来满意 ORDER BY,固然它会利用索引来找到记录来匹配 WHERE 子句.这些情形以下:
* 对差别的索引键做 ORDER BY :
SELECT * FROM t1 ORDER BY key1, key2;
* 在非持续的索引键部份上做 ORDER BY:
SELECT * FROM t1 WHERE key2=constant ORDER BY key_part2;
* 同时利用了 ASC 和 DESC:
SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 ASC;
* 用于搜索记录的索引键和做 ORDER BY 的不是同一个:
SELECT * FROM t1 WHERE key2=constant ORDER BY key1;
* 有很多表一同做衔接,并且读取的记录中在 ORDER BY 中的字段都不满是来自第一个非常数的表中（也就是说,在 EXPLAIN 解析的后果中的第一个表的衔接范例不是 const）.
* 利用了差别的 ORDER BY 和 GROUP BY 表达式.
* 表索引中的记录不是顺次存储.比方,HASH 和 HEAP 表就是这样.
通过履行 EXPLAIN SELECT ... ORDER BY,就知道MySQL能否在查询中利用了索引.假如 Extra 字段的值是 Using filesort,则阐明MySQL无法利用索引.详情请看"7.2.1 EXPLAIN Syntax (Get Information About a SELECT)".当必须对后果举行排序时,MySQL 4.1从前 它利用了以下 filesort 算法:
复制代码 代码以下:
1. 按照索引键读取记录,大概扫描数据表.那些无法匹配 WHERE 分句的记录城市被略过.
2. 在缓冲中每条记录都用一个‘对'存储了2个值（索引键及记录指针）.缓冲的大小根据系统变量 sort_buffer_size 的值而定.
3. 当缓冲慢了时,就运行 qsort（快速排序）并将后果存储在暂时文件中.将存储的块指针保存起来（假如全部的‘对'值都能保存在缓冲中,就无需成立暂时文件了）.
4. 履行上面的操作,直到全部的记录都读取出来了.
5. 做一次多重归并,将多达 MERGEBUFF（7）个区域的块保存在另一个暂时文件中.反复这个操作,直到全部在第一个文件的块都放到第二个文件了.
6. 反复以上操作,直到剩余的块数目小于 MERGEBUFF2 (15).
7. 在最后一次多重归并时,只有记录的指针（排序索引键的最后部份）写到后果文件中去.
8. 通过读取后果文件中的记录指针来顺次读取记录.想要优化这个操作,MySQL将记录指针读取放到一个大的块里,并且利用它来顺次读取记录,将记录放到缓冲中.缓冲的大小由系统变量 read_rnd_buffer_size 的值而定.这个步骤的代码在源文件 `sql/records.cc' 中.
这个逼近算法的一个问题是,数据库读取了2次记录:一次是预算 WHERE 分句时,第二次是排序时.固然第一次都成功读取记录了（比方,做了一次全表扫描）,第二次是随机的读取（索引键已经排好序了,但是记录并没有）.在MySQL 4.1 及更新版本中,filesort 优化算法用于记录中不只包含索引键值和记录的位置,还包含查询中要求的字段.这么做避免了需求2次读取记录.改良的 filesort 算法做法大致以下:
1. 跟从前一样,读取匹配 WHERE 分句的记录.
2. 相关于每个记录,都记录了一个对应的;‘元组'信息信息,包含索引键值、记录位置、以及查询中所需求的全部字段.
3. 按照索引键对‘元组'信息举行排序.
4. 顺次读取记录,不过是从已经排序过的‘元组'列表中读取记录,而非从数据表中再读取一次.
利用改良后的 filesort 算法相比本来的,‘元组'比‘对'需求占用更长的空间,它们很少恰好合适放在排序缓冲中（缓冲的大小是由 sort_buffer_size 的值决意的）.因此,这便大概需求有更多的I/O操作,招致改良的算法更慢.为了避免使之变慢,这种优化办法只用于排序‘元组'中额外的字段的大小总和超越系统变量 max_length_for_sort_data 的情形（这个变量的值设置太高的一个表象就是高磁盘负载低CPU负载）.想要提高 ORDER BY 的速度,首先要看MySQL可否利用索引而非额外的排序历程.假如不能利用索引,可以试着遵守以下战略:
* 增添 sort_buffer_size 的值.
* 增添 read_rnd_buffer_size 的值.
* 改正 tmpdir,让它指向一个有很多剩余空间的专用文件系统.
假如利用MySQL 4.1或更新,这个选项答应有多个途径用循环的格局.各个途径之间在 Unix 上用冒号（':'）脱离开来,在 Windows,NetWare以及OS/2 上用分号（';'）.可以操纵这个特点将负载平均分摊给几个目录.注意:这些途径必须是分布在差别物理磁盘上的目录,而非在同一个物理磁盘上的差别目录.
以上是“MySQL Order By索引优化办法[MySQL防范]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：
| 本文地址： | 与您的QQ/BBS好友分享! |
- 好的评价 如果您觉得此文章好，就请您
0%(0) 
- 差的评价 如果您觉得此文章差，就请您
0%(0) 
中查找“MySQL Order By索引优化办法”更多相关内容
中查找“MySQL Order By索引优化办法”更多相关内容评论内容只代表网友观点，与本站立场无关！
评论摘要(共 0 条，得分 0 分，平均 0 分)
查看完整评论