发现的一些问题

• 问题1

在过去的半年时间里，研发团队内部尝试抓了一波儿慢查询SQL跟进处理率。发现有些同学对于慢查询处理的思路就是看看有没有用到索引，没有用到就试图加一个，实在不行就甩锅给这种情况是历史设计问题或者自行判定为用户特殊操作下触发的小概率事件，随即便申请豁免掉...   其实问题没有根本上解决。

• 问题2

还有就是网络上经常可以看到一些类似这样的文章：

“慢SQL性能优化大全”

“慢SQL性能优化看这篇就够了”...  

其实内容大同小异，要么建议加索引，要么建议重写SQL....

怎么说呢？知识点是对的，但不全面，这个很容易误导新同学，哈哈哈。

本文初衷

在业务项目发展过程中，我们常常会面对要处理 MySQL 慢查询问题，那我们应该如何分析解决问题呢？

部分同学在处理MySQL慢查询时候主要思路是加索引来解决，确实加索引是一个很好的解决问题的手段，但不是全部。既然慢查询作为问题，那就需要明确问题发生原因，和解决问题路径分析， 授人以鱼不如授人以渔，让我们一起来解锁