ITPub博客

首页 > 数据库 > MySQL > mysql深入优化篇

mysql深入优化篇

原创 MySQL 作者:czxin788 时间:2015-08-08 10:57:48 0 删除 编辑

 

笔者根据博森瑞讲师的公开课整理而成


 

<!--more-->

 

 

 

 

找到案发现场,就是说找这些sql在哪。

         学一门数据库是需要过程的,需要总结发现问题,解决问题的思路。

         DBA是互联网的警察,需要发现罪犯在哪(和破案一样)。罪犯就是那些慢sql

        

 

 

 

         一个用户发起一个查询请求,首先在buffer pool看有没有缓存这条sql,如果完全匹配,而且权限又满足,那么直接就把这条sql返回给客户。如果没有完全匹配,就要把sql语句解析成数据库认识的语言,即query id,也就是这条sqlid,通过这个id就能找到这条sql的所在位置。接下来,就需要对处理不了的东西进行预处理,即看有没有语法错误,重新分析它的解析数,接着下一步,查询优化器对连接、排序进行计算,对子查询进行优化。把这些优化好的sql继续往下一步走,生成最优的执行计划,通过执行计划就知道该走哪条路,能够在最短的范围内找到这条sql。然后调用存储引擎到数据文件里找到所需要的数据。

         上述就是整个sql的运转过程。

         我们要知道上述哪一步会带来问题。

 

 

mysqlsql接过来之后,需要对sql进行解析和处理,处理完之后直接抛给存储引擎,让存储引擎到数据库里面去找数据。在存储引擎到数据文件找数据的过程中,可能会有人做dml操作,这时就需要把这些dml操作记录到日志里面。从日志中我们就可以分析整个的运行过程。从中找出是哪些sql造成数据库性能缓慢。

 

        

默认数据库是关闭gereral全量查询日志,开启该日志很多人说会很耗性能。实际上,在cpu 40%,完全可以开启该全量查询的日志,当我们采样完毕了再把该功能关闭。所有的操作都会记录到全量查询日志里面。

找到慢sql,然后和开发沟通,说这个sql慢,问开发是改业务,还是在数据库改sql语句。

全量查询日志可以记录所有的查询和dml语句。

 

long_query_time=0表示所有的都记录。

 

mysql慢查询的工具:

mysqldumpslow 找出top 10,按照时间的大小,按照次数的多少进行排序。

pt-query-digest

 

 

 

上图包含:主机名,我的慢查询日志在哪个文件里面,所有sql的执行时间,这条sql的最大的执行时间,最小时间的执行时间、平均时间,这条sql锁定的时间。我采样的这个sql是从几点到几点的。我们可以采样24小时内的,我们也可以采样12小时内的。

 


 

 

根据这条sql query id,就可以找到这条sql语句。

calls,这个sql被调用的次数。

        

         上面的第一条sql执行了830s,执行了84次。这个sql太影响系统的性能,太需要优化了。

 

 

 

上述update子句中也包含select,通过对这个select 进行explain,看哪个字段需要加索引,或者调整业务就可以。

不要抱怨任何人,开发写的sql差,那我们就能写好这个sql吗。

        

         explain主要看是不是走索引了,再看扫描的行数。

         如果我想要做一件事,我需要把工具准备好,这样我才能应用我们所学的知识。

         我们要优化影响数据库主业务的sql,对不影响数据库主业务的sql没有必要优化。

         我们要优化并发度高的sql,和查询慢的sql

 

        

 

         记录主从有没有延迟,就需要用一些工具,把差异的数据记录到一张表里面。

         怎么找导致主从之间延迟最厉害的sql,这样导致主从之间延迟慢的sql不会记录到慢查询日志里面。

         我们可以开启log_slow_slave_statements,可以记录导致主从复制延迟的sql

 



来自为知笔记(Wiz)


附件列表

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/28916011/viewspace-1765361/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2014-06-03

  • 博文量
    184
  • 访问量
    578914