Mysql学习MySQL优化全攻略-相关数据库命令
发布时间:2020-12-12 01:08:56 所属栏目:MySql教程 来源:网络整理
导读:《Mysql学习MySQL优化全攻略-相关数据库命令》要点: 本文介绍了Mysql学习MySQL优化全攻略-相关数据库命令,希望对您有用。如果有疑问,可以联系我们。 接下来我们要讨论的是数据库性能优化的另一方面,即运用数据库服务器内建的工具辅助性能分析和优化.?? ?
《Mysql学习MySQL优化全攻略-相关数据库命令》要点: ?▲?SHOW?? ?执行下面这个命令可以了解服务器的运行状态:?? mysql?>show?status;? ?该命令将显示出一长列状态变量及其对应的值,其中包括:被中止访问的用户数量,被中止的连接数量,尝试连接的次数,并发连接数量最大值,以及其他许多有用的信息.这些信息对于确定系统问题和效率低下的原因是十分有用的.?? ?SHOW命令除了能够显示出MySQL服务器整体状态信息之外,它还能够显示出有关日志文件、指定数据库、表、索引、进程和许可权限表的宝贵信息.请访问http://www.mysql.com/doc/S/H/SHOW.html了解更多信息.?? ?▲?EXPLAIN?? ?EXPLAIN能够分析SELECT命令的处理过程.这不仅对于决定是否要为表加上索引很有用,而且对于了解MySQL处理复杂连接的过程也很有用.?? ?下面这个例子显示了如何用EXPLAIN提供的信息逐步地优化连接查询.(本例来自MySQL文档,见http://www.mysql.com/doc/E/X/EXPLAIN.html.原文写到这里似乎有点潦草了事,特加上此例.)?? ?假定用EXPLAIN分析的SELECT命令如下所示:?? EXPLAIN?SELECT?tt.TicketNumber,?tt.TimeIn,? ??????tt.ProjectReference,?tt.EstimatedShipDate,? ??????tt.ActualShipDate,?tt.ClientID,? ??????tt.ServiceCodes,?tt.RepetitiveID,? ??????tt.CurrentProcess,?tt.CurrentDPPerson,? ??????tt.RecordVolume,?tt.DPPrinted,?et.COUNTRY,? ??????et_1.COUNTRY,?do.CUSTNAME? ????FROM?tt,?et,?et?AS?et_1,?do? ????WHERE?tt.SubmitTime?IS?NULL? ??????AND?tt.ActualPC?=?et.EMPLOYID? ??????AND?tt.AssignedPC?=?et_1.EMPLOYID? ??????AND?tt.ClientID?=?do.CUSTNMBR;? ?SELECT命令中出现的表定义如下:?? ?※表定义?? 表?列?列类型?? tt?ActualPC?CHAR(10)?? tt?AssignedPC?CHAR(10)?? tt?ClientID?CHAR(10)?? et?EMPLOYID?CHAR(15)?? do?CUSTNMBR?CHAR(15)?? ?※索引?? 表?索引?? tt?ActualPC?? tt?AssignedPC?? tt?ClientID?? et?EMPLOYID?(主键)?? do?CUSTNMBR?(主键)?? ?※tt.ActualPC值分布不均匀?? ?在进行任何优化之前,EXPLAIN对SELECT执行分析的结果如下:?? table?type?possible_keys????????key?key_len?ref?rows?Extra? et??ALL?PRIMARY???????????NULL?NULL??NULL?74? do??ALL?PRIMARY???????????NULL?NULL??NULL?2135? et_1?ALL?PRIMARY???????????NULL?NULL??NULL?74? tt??ALL?AssignedPC,ClientID,ActualPC?NULL?NULL??NULL?3872? ???range?checked?for?each?record?(key?map:?35)? ?每一个表的type都是ALL,它表明MySQL为每一个表进行了完全连接!这个操作是相当耗时的,因为待处理行的数量达到每一个表行数的乘积!即,这里的总处理行数为74?*?2135?*?74?*?3872?=?45,268,558,720.?? ?这里的问题之一在于,如果数据库列的声明不同,MySQL(还)不能有效地运用列的索引.在这个问题上,VARCHAR和CHAR是一样的,除非它们声明的长度不同.由于tt.ActualPC声明为CHAR(10),而et.EMPLOYID声明为CHAR(15),因此这里存在列长度不匹配问题.?? ?为了解决这两个列的长度不匹配问题,用ALTER?TABLE命令把ActualPC列从10个字符扩展到15字符,如下所示:?? mysql?>?ALTER?TABLE?tt?MODIFY?ActualPC?VARCHAR(15);? ?现在tt.ActualPC和et.EMPLOYID都是VARCHAR(15)了,执行EXPLAIN进行分析得到的结果如下所示:?? table?type??possible_keys??key???key_len?ref?????rows??Extra? tt??ALL??AssignedPC,ActualPC?NULL?NULL?NULL?3872??where?used? do??ALL??PRIMARY?????NULL??NULL??NULL????2135? ???range?checked?for?each?record?(key?map:?1)? et_1?ALL??PRIMARY?????NULL??NULL??NULL????74? ???range?checked?for?each?record?(key?map:?1)? et??eq_ref?PRIMARY?????PRIMARY?15???tt.ActualPC?1? ?这还算不上完美,但已经好多了(行数的乘积现在少了一个系数74).现在这个SQL命令执行大概需要数秒钟时间.?? ?为了避免tt.AssignedPC?=?et_1.EMPLOYID以及tt.ClientID?=?do.CUSTNMBR比较中的列长度不匹配,我们可以进行如下改动:?? mysql?>?ALTER?TABLE?tt?MODIFY?AssignedPC?VARCHAR(15),? ???????????MODIFY?ClientID??VARCHAR(15);? ?现在EXPLAIN显示的结果如下:?? table?type??possible_keys??key???key_len?ref??????rows???Extra? et??ALL??PRIMARY?????NULL??NULL??NULL??????74? tt??ref??AssignedPC,ActualPC?ActualPC?15?et.EMPLOYID?52?where?used? et_1?eq_ref?PRIMARY?????PRIMARY?15???tt.AssignedPC?1? do??eq_ref?PRIMARY?????PRIMARY?15???tt.ClientID??1? ?这个结果已经比较令人满意了.? ?余下的问题在于,默认情况下,MySQL假定tt.ActualPC列的值均匀分布,而事实上tt表的情况并非如此.幸而,我们可以很容易地让MySQL知道这一点:?? shell?>?myisamchk?--analyze?PATH_TO_MYSQL_DATABASE/tt? shell?>?mysqladmin?refresh? ?现在这个连接操作已经非常理想,EXPLAIN分析的结果如下:?? table?type??possible_keys??key???key_len?ref??????rows??Extra? tt??ALL??AssignedPC,ActualPC?NULL?NULL?NULL??3872??where?used? et??eq_ref?PRIMARY?????PRIMARY?15???tt.ActualPC??1? et_1?eq_ref?PRIMARY?????PRIMARY?15???tt.AssignedPC?1? do??eq_ref?PRIMARY?????PRIMARY?15???tt.ClientID??1? ?▲?OPTIMIZE?? ?OPTIMIZE能够恢复和整理磁盘空间以及数据碎片,一旦对包含变长行的表进行了大量的更新或者删除,进行这个操作就非常有必要了.OPTIMIZE当前只能用于MyISAM和BDB表.?? ?结束语:从编译数据库服务器开始、贯穿整个管理过程,能够改善MySQL性能的因素实在非常多,本文只涉及了其中很小的一部分.尽管如此,我们希望本文讨论的内容能够对你有所帮助.?? //copy者注:? (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |