案例1 

背景：测试环境下发现大量select查询，而且负载飙升到90+

排查思路:

              1 老规则，按照排错脚本走一圈，规划出几个元素(1 针对库访问的统计 2针对具体语句类型的统计),发现有大量的select 查询

              2  考虑 是因为没有走索引导致的sql堆积么，我explain了一下，速度很快。

              3  那么得出结论是由于并发导致的问题。

问题解决:

              1既然是并发问题， 联系到了相关的研发人员，发现是由于mysql前端的redis挂掉了，导致直接大量查询打到了mysql端，负载飙升

              2 研发停止了相关查询，问题解决

总结: 对于前端做mysql缓存的redis这种架构，一定也要关注，一旦redis发生问题，大量查询会拖垮mysql本身。排查问题不光要从mysql本身考虑

这就是我的一点感悟

案例 2

背景: 线上并发查询导致主库负载飙升

排查思路:

    1 由于线上飙升大量select导致阻塞,采用批量kill方法干掉慢查询,但是没有太多用,程序不断尝试

    2 都是由于一条语句导致的,explain和手动在从库执行下发现用了0.89s(这里觉得已经很快了,就没注意)

    3 没办法，只能研发人员进行反复排除,进入大坑

问题解决:

    解决问题进入了误区,无意之中尝试优化了下语句,加入了相关索引，立刻恢复了。。。,语句执行从0.89~0.03s，

总结: 1 语句优化要彻底,我因为觉得0.89s已经很快,所以掉入了误区,以后一定引以为戒

         2 大量并发标准执行时间最好少于0.2s