项目在全国推广过程中，随着用户量及业务数据的增加，前期的临时优化策略渐渐支撑不住.
通过日常监测，发现近期数据库CPU压力数次飙升到100%，虽没有导致应用崩溃，但是已经严重影响到系统性能及用户体验，且随时面临微服务崩溃的情况。
经过慢SQL分析，对CPU飙升至100%时前后近6小时的慢SQL洞察，按耗时排名，Top3 慢SQL占了总耗时99%。如下图所示:
慢SQL耗时TOP排名
从图中可以看到，TOP1慢SQL占了总耗时90%以上，解决了该SQL的性能问题，就能大大缓解数据库的压力。
对TOP1 慢SQL详细分析中，发现了诡异的一幕，在7月3日下午15.06分，15.17分，15.50分左右该SQL的执行次数从0突升至几十或上百，很不正常，如图所示:
慢SQL分析
因为该SQL执行结果存redis缓存的，除非出现缓存过期或清理缓存的操作，不然不会出现大量差库的操作。
下一步就是对redis的分析，发现在7月3日下午15.06，15.17，15.50左右确实出现了keys数量陡降的过程，正好与该SQL的运行现象吻合，如下图：
redis缓存keys分析
当redis keys陡降之后，数据库的压力会飙升上来，项目的redis缓存与数据库压力存在负相关性，如下图：
数据库CPU压力分析（在redis keys值陡降的15:06分，15:17分，15:50分左右，数据库CPU压力飙升至100%）
接下来就是更改缓存策略及慢SQL的优化，截止当晚10点左右已完成对影响最大的几个慢SQL的改造工作。
