MySQL 数据库性能优化之索引优化.doc

MySQL 数据库性能优化之索引优化.doc

ID:61513007

大小:19.00 KB

页数:5页

时间:2021-02-09

MySQL 数据库性能优化之索引优化.doc_第1页
MySQL 数据库性能优化之索引优化.doc_第2页
MySQL 数据库性能优化之索引优化.doc_第3页
MySQL 数据库性能优化之索引优化.doc_第4页
MySQL 数据库性能优化之索引优化.doc_第5页
资源描述:

《MySQL 数据库性能优化之索引优化.doc》由会员上传分享,免费在线阅读,更多相关内容在应用文档-天天文库

1、这篇文章是以MySQL为背景,很多内容同时适用于其他关系型数据库,需要有一些索引知识为基础  优化目标  减少IO次数  IO永远是数据库最容易瓶颈的地方,这是由数据库的职责所决定的,大部分数据库操作中超过90%的时间都是IO操作所占用的,减少IO次数是SQL优化中需要第一优先考虑,当然,也是收效最明显的优化手段。  降低CPU计算  除了IO瓶颈之外,SQL优化中需要考虑的就是CPU运算量的优化了。orderby,groupby,distinct…都是消耗CPU的大户(这些操作基本上都是CPU处理内存中的数据比较运算)。当我们的IO优化

2、做到一定阶段之后,降低CPU计算也就成为了我们SQL优化的重要目标  优化方法  改变SQL执行计划  明确了优化目标之后,我们需要确定达到我们目标的方法。对于SQL语句来说,达到上述2个目标的方法其实只有一个,那就是改变SQL的执行计划,让他尽量“少走弯路”,尽量通过各种“捷径”来找到我们需要的数据,以达到“减少IO次数”和“降低CPU计算”的目标  常见误区  count(1)和count(primary_key)优于count(*)  很多人为了统计记录条数,就使用count(1)和count(primary_key)而不是coun

3、t(*),他们认为这样性能更好,其实这是一个误区。对于有些场景,这样做可能性能会更差,应为数据库对count(*)计数操作做了一些特别的优化。  count(column)和count(*)是一样的  这个误区甚至在很多的资深工程师或者是DBA中都普遍存在,很多人都会认为这是理所当然的。实际上,count(column)和count(*)是一个完全不一样的操作,所代表的意义也完全不一样。  count(column)是表示结果集中有多少个column字段不为空的记录  count(*)是表示整个结果集有多少条记录  selecta,bfr

4、om…比selecta,b,cfrom…可以让数据库访问更少的数据量  这个误区主要存在于大量的开发人员中,主要原因是对数据库的存储原理不是太了解。  实际上,大多数关系型数据库都是按照行(row)的方式存储,而数据存取操作都是以一个固定大小的IO单元(被称作block或者page)为单位,一般为4KB,8KB…大多数时候,每个IO单元中存储了多行,每行都是存储了该行的所有字段(lob等特殊类型字段除外)。  所以,我们是取一个字段还是多个字段,实际上数据库在表中需要访问的数据量其实是一样的。  当然,也有例外情况,那就是我们的这个查询在

5、索引中就可以完成,也就是说当只取a,b两个字段的时候,不需要回表,而c这个字段不在使用的索引中,需要回表取得其数据。在这样的情况下,二者的IO量会有较大差异。  orderby一定需要排序操作  我们知道索引数据实际上是有序的,如果我们的需要的数据和某个索引的顺序一致,而且我们的查询又通过这个索引来执行,那么数据库一般会省略排序操作,而直接将数据返回,因为数据库知道数据已经满足我们的排序需求了。  实际上,利用索引来优化有排序需求的SQL,是一个非常重要的优化手段  延伸阅读:MySQLORDERBY的实现分析,MySQL中GROUPBY

6、基本实现原理以及MySQLDISTINCT的基本实现原理这3篇文章中有更为深入的分析,尤其是第一篇  执行计划中有filesort就会进行磁盘文件排序  有这个误区其实并不能怪我们,而是因为MySQL开发者在用词方面的问题。filesort是我们在使用explain命令查看一条SQL的执行计划的时候可能会看到在“Extra”一列显示的信息。  实际上,只要一条SQL语句需要进行排序操作,都会显示“Usingfilesort”,这并不表示就会有文件排序操作。  延伸阅读:理解MySQLExplain命令输出中的filesort,我在这里有更

7、为详细的介绍  基本原则  尽量少join  MySQL的优势在于简单,但这在某些方面其实也是其劣势。MySQL优化器效率高,但是由于其统计信息的量有限,优化器工作过程出现偏差的可能性也就更多。对于复杂的多表Join,一方面由于其优化器受限,再者在Join这方面所下的功夫还不够,所以性能表现离Oracle等关系型数据库前辈还是有一定距离。但如果是简单的单表查询,这一差距就会极小甚至在有些场景下要优于这些数据库前辈。  尽量少排序  排序操作会消耗较多的CPU资源,所以减少排序可以在缓存命中率高等IO能力足够的场景下会较大影响SQL的响应时

8、间。  对于MySQL来说,减少排序有多种办法,比如:  上面误区中提到的通过利用索引来排序的方式进行优化  减少参与排序的记录条数  非必要不对数据进行排序  …  尽量避免select* 

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。