工作经验~如何高效的处理慢日志

一 简介:今天来聊聊如何高效率的处理慢日志

二 背景:随着DB业务越来越多,慢sql也会越来越多,如何高效的处理这些慢sql,我说下我的观点

三 基础:

           1 需要建立一个统一的收集和发送平台

              1 收集是指收集慢日志到统一数据库 2发送 是指发送邮件到邮件组,

                 我推荐用lepus/PMM,都是比较成熟的功能

                 DB的慢日志最好按照按小时切割,这样容易管理

            2 建立DB与负责人员对应列表

               1 这样可以快速根据DB定位到个人,尤其是在DB越来越多的情况下,非常必要

               2 可以根据负责人员获取sql优化的反馈进度

           3  建议建立慢语句追踪机制

                 可以采用提工单形式,慢语句分为 未解决 处理中 处理完三个阶段.建立一个追踪机制,才能高效的和研发联动一起处理慢语句

四 针对慢sql的分类:

             1 可以被直接去掉的慢sql,这类sql通常是过期的业务task,直接下线

             2 可以降低频率的慢sql，这类sql通常是周期性统计,可以降低频率的,减少IO交互

             3 (执行频率高,扫描行数超过百万,结果集相差太大的) 拥有这类特征sql语句是我们重点的关注对象,该加索引的加索引,该改写的改写

             4 暂时不能被优化的sql  比如全表查询的分页操作 比如业务暂时不能更改的sql(特殊场景)

             5 针对一些查询可以考虑分离到从库进行操作,减少主库的压力

             6 升级你的硬件,用SSD代替机械硬盘,减少随机IO的次数,提升查询效率

             7 定期清除归档热表数据,确保表的数据不要太大,非常重要,保持表的数据量不要超过1千万

五 总结:

            慢查询是一个数据库健康程度的体现指标之一,所以要保证数据库正常的运行,要减少甚至避免慢查询语句的出现 大部分CPU暴涨的情况都是慢查询导致

六 补充

           1 建议按照小时对慢日志进行切割,远程进行收集展示

           2 建议按照周或者月份统一对线上所有慢查询统一优化,形成周期性工作.用以持续保障线上安全

七 备注 如何分析天兔切割的慢日志

     1 根据每小时生成的慢日志文件大小定位数据库高峰时段,分析问题 du -sh *log即可

     2 根据不同用户角度定位具体的相关库 cat slowquery_2019*.log |grep User|awk '{print $3}'|sort | uniq -c | sort -n

    3  根据扫描行数与花费时间的角度进行归类统计 cat slowquery_2019*.log |grep -B1 Row|awk '{ if ($NF >=100000){print $2,$3,$8,$NF}} -》统计大于10W行的相关信息

           

转载于:https://www.cnblogs.com/danhuangpai/p/9378836.html