案例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