问题排查
问题说明： 每天固定时间点，系统会瘫痪，然后过了这个时间点，系统自动就恢复。
问题排查： 系统能自动恢复，基本可以排除后台服务被大量请求打死的可能性，因为如果进程被打死了，一般是不会自动恢复的。
排查重点放在Mysql上，发现mysql的cpu利用率一直是100%，MySQL 这种 CPU 利用率高的现象，绝大多数情况都是由慢 SQL 导致的，所以我们优先排查慢 SQL。
当数据库非常忙的时候，它执行任何一个 SQL 都很慢。所以，并不是说，慢 SQL 日志中记录的这些慢 SQL 都是有问题的 SQL。大部分情况下，导致问题的 SQL 只是其中的一条或者几条。不能简单地依据执行次数和执行时长进行判断，但是，单次执行时间特别长的 SQL，仍然是应该重点排查的对象。
排查结果：有慢sql，缓存失效穿透到数据库
开发建议
- 在编写 SQL 的时候，一定要小心谨慎地仔细评估。先问自己几个问题：
- 你的 SQL 涉及到的表，它的数据规模是多少？
- 你的 SQL 可能会遍历的数据量是多少？
- 尽量地避免写出慢 SQL。
- 能不能利用缓存减少数据库查询次数？在使用缓存的时候，还需要特别注意的就是缓存命中率，要尽量避免请求命中不了缓存，穿透到数据库上。
架构建议
- 上线一个定时监控和杀掉慢 SQL 的脚本。
- 做一个简单的静态页面的首页作为降级方案。在 Nginx 上做一个策略，如果请求首页数据超时的时候，直接返回这个静态的首页作为替代。这样后续即使首页再出现任何的故障，也可以暂时降级，用静态首页替代。至少不会影响到用户使用其他功能。
此文章为3月Day8学习笔记，内容来源于极客时间《后端存储实战课》
