客户跟我反馈他们的数据库通过客户端数据库工具连接不上了，并且截图我看了，数据库是mysql
报错内容"MySQL error: 2013, “Lost connection to MySQL server at ‘reading initial communication packet‘, system error: 0""2丶思路分析
- 查看数据库错误日志
- 查看系统日志
3丶开始排查
【第一步】
开启两个"session"，一个用于实时监控mysql的错误日志，而且奇怪的是错误日志最后一条信息的输出时间为2020/08/04，
我就觉得很奇怪，今天都8月5号来了，难道这段时间数据库都不输出日志的吗？
但是由于间隔时间不长，然后数据库也连接不上，我先入为主的认为可能数据库已经假死，
导致日志信息都不输出，所以我并没有在意！【第二步】
我开始启动数据库，但是还是启动失败，但是错误日志还是没有任何输出，我就觉得很奇怪，
"磁盘空间也没满"，为什么我连重启数据库怎么也不输出错误日志呢，没错误日志排查不就是盲查吗?【第三步】
错误日志行不通，于是我就去看了下系统日志message，或许能找到点有用的信息，
突然发现里面打印了一条"no many open file"，难道是因为进程打开的文件数超过了默认的设置限制吗？
我通过"ulimit -n" 看了下发现进程打开的文件数是65535而我mysql这刚启动怎么可能出现超过"65535"的可能，
于是我判断应该是有某个进程打开了文件数超过了"65535"，但是我又不想也不对啊，
即使某个进程超过了"65535"的限制但是我"mysql"不受影响啊，难道是说系统打开的文件数达到了上限？
于是我通过"sysctl -a|grep fs.file"查看系统的限制发现也是"65535"，原来是系统达到了临界点了，
于是我就通过"lsof |wc -l "查看当时系统打开的文件数，发现已经达到"70000"多了，终于找到了原因了-
排序当前系统中打开文件数前十的进程
lsof |awk ‘{print $1}‘|sort|uniq -c |sort -nr|head -10 - 确认java进程打开的文件数
【第四步】
找到了原因接下来就是查看哪个进程打开的文件数最多了，发现是"java程序导致"的，
于是就反馈给我们客户让他找相关的开发同事着重排查下，
是不是打开文件的时候未"close"文件总结
1丶由于系统打开文件数上限，导致mysql错误日志无任何日志输出
2丶不要盲目的去尝试，通过看日志排错是最好的选择
3丶当自己的才华不足以满足自己的野心时，记得静下心来学习