本文希望表达的是：在遇到问题的时候，要有明确的思路和数据。不要随便猜。很多人在看到这问题的时候，就会问是不是redis雪崩了，是不是连接数过多了，这个是最low的。一般能直接定位的问题就不是问题了。
开发者是要学会思考的。遇到问题不要拍头猜问题。要有解决的思路。该问题的的答案是我个人的。每个人如果有兴趣可以想想，从这道题出发，自己的思路是什么。
提出有用的问题，获得想要的答案，一步一步定位问题。
场景
问题是：我们的一个数据库进程挂了，你来定位一下问题在哪里？ 你可以提出各种你认为有价值的问题，我给你各种数据反馈，直到你定位到问题在哪里。
总体的指导思想
出问题的时候，一般都会有一些指标会有异常
解决问题的前提
你对正常情况下的指标和业务的架构都比较清楚，不清楚的前提先弄清楚，或者有之前的指标可以对比，而且不仅仅停留在数据库本身
剩下的其他的，都是解决方法的问题，至于哪个方法好用，主要根据实际业务场景的一些情况，
先用最简单的方法定位问题的范围，然后逐步找到问题并解决问题
我的思路
提出每个问题，并提出自己想要得到的数据
- 这个数据库是什么业务在用的？
【希望】：了解业务场景，看是否有访问峰值，初步了解该业务特点。
- 数据库挂掉的大概时间
【希望】：和第一个问题相呼应，看是否能得出什么提示。如高峰时数据库挂掉。
- 是否有主从和读写分离
【希望】：了解数据库是否有主从结构，几主几从。是否有做读写分离
- 若有3，是主库挂掉还是从库挂掉
【希望】：则从主库挂掉或者从库挂掉可以大概知道是读还是写导致的数据库挂掉（注意这里不能确定判断，只是有个大概方向）。
- 系统的结构（数据库在系统中所处的位置和作用）
【希望】：代码的逻辑层都是直连数据库，还是中间有缓存层（全部 or 局部）。
- 系统监控数据是否有异常
【希望】：
mysql监控信息，连接数，慢查询，读写比例等，sql执行的qps等。
cpu负载，内存使用，硬盘容量。看是否有异常，可能导致数据库进程挂掉。
缓存机器or集群的健康状况： 若缓存层有状况，看是否是存在雪崩的情况（若是雪崩，mysql的监控信息，应该会给出警报）
- 日志排查
【希望】： 通过查看mysql错误日志，二进制日志或系统错误日志等日志，希望可以得到进程挂掉的时间段是否有相应的错误提示信息。
- 是否有人主动杀掉
【希望】： 在上面的过程中，一般能从技术上定位到问题了。这一步可以从非技术的角度分析。看是否是有管理员或者某个脚本或进程误停掉进程。更甚，看一下机器是否被入侵。被恶意杀掉进程。
后续
上面的过程是基于前面条件不成立的情况下的排查思路。在排查期间，会有很多分支的情况。
- 比如：在业务高峰访问的点挂掉？
则就需要判断为什么这个点会挂掉。是代码发布原因，还是系统的突发状况。
- 比如： 已经知道连接数过多导致的进程挂掉？
则就需要排查为什么连接数过多，是业务上的原因（如上线活动），还是sql执行的原因（慢查询导致连接关闭不了）等等
- 比如：cpu负载过高？
为什么cpu的负载过高？是其他服务占用了cpu，还是mysql本身的占用了cpu（为什么占用了cpu）
等等，等等
问题的排查，在不是很明确的情况下，每一个猜测应该是有依据的。
