mysql 慢sql自动化优化处理和跟踪

背景:
数据库的工作中,最常见就是慢sql优化了,但是DBA怎么才能从这种繁杂的工作中抽出身来,比前就是自己去数据库里查,或者其他的途径发现一个慢sql,然后就丢给开发,DBA就像一个后妈一样在跟在屁股后面去催开发优化,这个方式不但工作效率低下,也影响消耗DBA的时间,DBA应该从这些日常繁杂的事情中抽身出来去对接业务,研究新技术,架构等,更多时间去做一些更加有价值的事情
解决方案:
目前公司的主要业务都在放在阿里云的RDS上,阿里云提供接口去访问慢sql日志
一,原数据准备
1,写一个小程序定时去抽取所有实例的慢sql存放在表中
2,把所有的sql打上标签,方便后面的分析
3,输出慢sql的执行计划并存储在表中
二,数据分析和慢sql处理流程
1,通过这些原数据,从sql执行时间,次数,扫描的行数,排序,索引的使用情况等多个维度来分析sql,并输出分析结果
2,把经过处理的慢sql和tapd项目管理系统打通,把每个sql自动分配到相关的开发责任人
3,输出优化结果报表,每个项目每周的慢sql优化情况
三总结:
1,通过这种方式可以减少DBA的工作量
2,通过平台来管理和跟踪慢sql的优化,会让整个工作流更加清晰和高效
3,通过报表让整个优化工作更加清晰,调动开发积极性,让得优化工作可以量化

四,代码和结果截图:
1,拉取慢sql:

2,结果生成Html

3,生成报表:

结果展示:
1,慢sql日志:

2,tapd工单:

3,报表:

唠叨:
1,因为代码码也比较多,所以只是随便贴了一点代码
2,只是展示其中一些输出结果
3,目前还没有做成平台,因为俺的前端开发还不大会,哈哈!目前先做成这样子,但是这样也能有效提高工作效率了
4,在这里只抛砖引玉,和大家分享一下自己的一些思路,欢迎大家留言,期待大牛的方案和指导,谢谢

原文地址:http://blog.51cto.com/538858/2327460

时间: 12-07

mysql 慢sql自动化优化处理和跟踪的相关文章

MySQL之SQL语句优化

一 SQL语句优化的一般步骤: 1 通过show status命令了解各种SQL语句的执行频率 mysql> show status;                #show status:显示服务器状态信息 +-----------------------------------------------+-------------+ | Variable_name                                 | Value       | +---------------

千万级大数据的Mysql数据库SQL语句优化

1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:select id from t where num is null可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:select id from t where num=0 3.应尽量避免在 where 子句中使用!=或<>操作符,否则引擎将放弃使用

Mysql性能优化----SQL语句优化、索引优化、数据库结构优化、系统配置优化、服务器硬件优化

一.SQL语句优化 1-1.MySQL慢日志 1).慢日志开启方式和存储格式 如何发现有问题的SQL? 使用Mysql慢日志对有效率问题的SQL进行监控 前期准备 mysql> show variables like '%log_queri%'; +-------------------------------+-------+ | Variable_name | Value | +-------------------------------+-------+ | log_queries_no

MySql数据库3【优化2】sql语句的优化

1.SELECT语句优化 1).利用LIMIT 1取得唯一行[控制结果集的行数] 有时,当你要查询一张表是,你知道自己只需要看一行.你可能会去的一条十分独特的记录,或者只是刚好检查了任何存在的记录数,他们都满足了你的WHERE子句.在这种情况下,增加一个LIMIT 1会令你的查询更加有效.这样数据库引擎发现只有1后将停止扫描,而不是去扫描整个表或索引. 2).不要使用BY RAND()命令 这是一个令很多新手程序员会掉进去的陷阱.你可能不知不觉中制造了一个可怕的平静.这个陷阱在你是用BY RAN

美图秀秀DBA谈MySQL运维及优化

https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=401797597&idx=2&sn=a0fc08dbb8ce399f0d4cd70bff5b1366&scene=0&key=62bb001fdbc364e56abc83575de147aa1f6fe32d5f4bad7190eadb03350bcfba18b0c9740d43855a5b45e5286bd457cd&ascene=7&uin

MySql学习(六) —— 数据库优化理论(二) —— 查询优化技术

逻辑查询优化包括的技术 1)子查询优化  2)视图重写  3)等价谓词重写  4)条件简化  5)外连接消除  6)嵌套连接消除  7)连接消除  8)语义优化 9)非SPJ优化 一.子查询优化 1. 什么是子查询:当一个查询是另一个查询的子部分时,称之为子查询. 2. 查询的子部分,包含的情况: a) 目标列位置:子查询如果位于目标列,则只能是标量子查询,否则数据库可能返回类似“错误:子查询只能返回一个字段 ( [Err] 1242 - Subquery returns more than 1

MySql:监控及优化

1.mysql的生命周期 ①MySql服务器监听3306端口 ②验证访问用户 ③创建mysql线程 ④检查内存(Qcache) ⑤解析sql ⑥生成查询计划 ⑦打开表 ⑧检查内存(Buffer Pool) ⑨到磁盘取数据 ⑩写入内存 ①①返回数据给客户端 ①②关闭表 ①③关闭线程 ①④关闭连接 2.mysql配置 linux下两种进入mysql的方式: ①设置别名 ②将mysql的/opt/lampp/bin/目录加入环境变量 ③让设置的别名永久生效 vi ~/.bashrc alias my=

SQL性能优化案例分析

这段时间做一个SQL性能优化的案例分析, 整理了一下过往的案例,发现一个比较有意思的,拿出来给大家分享. 这个项目是我在项目开展2期的时候才加入的, 之前一期是个金融内部信息门户, 里面有个功能是收集各个上市公司的财报, 然后做各种分析, 数据图表展示, 使用的人数并不多, 仅百人左右. 2期打算面向行外用户, 刚开始预计同时在线人数不超过50, 就以50访问用户/秒的性能测试, 结果在把1期的图表类数据展示响应基本在5分钟左右, 属于严重不可用, 说说我们的服务器配置, 有2台网站前端承载用户

转:sql语句优化

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行.

SQL语句优化原则

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行.