安全黑客
当前位置:安全黑客文章资讯数据防范MySQL防范
日期: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防范]”的内容,如果你对以上该文章内容感兴趣,你可以看看安全黑客为您推荐以下文章:
  • Windows 搭配 IIS7 PHP MySQL 环境
  • 某电器网站客服中央mysql字符型盲注及修复
  • mysql Out of memory (Needed 16777224 bytes)的错误办理
  • mysql提醒[Warning] Invalid (old?) table or database name问题的办理办法
  • mysql启用skip-name-resolve情势时呈现Warning的处理办法
  • mysql启用skip-name-resolve情势时呈现Warning的处理办法
  • MySQL Order By语法介绍
  • <b>MySQL ORDER BY 的实现解析</b>
  • mysql数据库插入速度和读取速度的调整记录
  • MySQL Order By索引优化办法
  • MySQL Order By用法分享
  • mysql #1062 –Duplicate entry ''1'' for key ''PRIMARY''
  • 本文地址: 与您的QQ/BBS好友分享!

    文章评论评论内容只代表网友观点,与本站立场无关!

       评论摘要(共 0 条,得分 0 分,平均 0 分) 查看完整评论
    免责条款 - 广告合作 - 下载声明 - 欢迎投稿 - 友情连接 - 网站地图 -
    Copyright © 2012-2013 www.110hack.com. All Rights Reserved .