江苏龙网

  1. 主页 > 生活百科 > >

一条MySQL报警的分析思路( 二 )

MySQL报警


其实到了这里 ， 我们的分析还是不够深入 ， 我们可以发掘出更多的信息 ， 那就是可以提供给业务方一个更全面的信息列表 ， 比如那些表中的索引是冗余索引 ， 那些表走了全表扫描需要考虑添加索引 。
这里需要正确引用sys schema,比如：

一条MySQL报警的分析思路

文章插图
 
通过如上的信息可以发现我们需要重点考虑前面的几个表 ， 走了全表扫描 ， 产生了较大的延迟 。
而稍后的解决方法 ， 其实是通过对于业务的反馈优化 ， 在业务添加了相关索引之后 ， 还是建议打开参数：log_queries_not_using_indexes  ， 这对于一些业务场景的监控其实也是有效的 。
如此一来 ， 我们对慢日志的分析也告一段落 ， 如果对于每条报警信息我们都认真对待 ， 其实相应技术能力的提升也会很快 。
其实行业里有一个常见的“伪需求“ ， 就是开发同学经常需要关注慢日志 ， 从工作的角色和分工来看 ， 他们得到慢日志之后的分析和处理常常和问题的本质相左 ， 换句话说 ， 他们得到慢日志 ， 是希望通过分析日志来发现一些明显的性能问题 ， 通过这种信息检索的方式 ， 来快速定位问题 ， 但是实际上得到日志之后的分析结果是不可控的 ， 可能10分钟 ， 可能分析不出来 。
而这个工作其实是应该作为运维的前置工作来完成的 ， 既然开发对于慢日志的处理不专业 ， 势必需要DBA来提供专业的建议 ， 而如果我们能够通过一种透明自助的方式来提供分析和有效建议 ， 对于开发同学来说 ， 其实他们需要的不是慢日志 ， 而是你的数据服务能力 。




推荐阅读


上一篇：C++ 一篇搞懂多态的实现原理

下一篇：在你开始打算做网站躺着赚钱时，必须知道服务器1核和2核的区别