问题背景
在多个月之前，也就是服务器刚刚搭建的时候，标题中的MySQL问题就出现了，很是奇怪，博客过一段时间就毫无征兆的挂掉了，提示连接数据库失败，然后重新启动一下MySQL服务就又可以正常运行了。但是这个问题总是像莫名其妙的发生，时不时的给我来一点小惊喜，小意外，我每次重启MySQL服务之后就又可以正常运行了，所以就没去怎么解决这个问题。但是最近真的是忍无可忍了，决定解决了它。
先说一下我的服务器情况：
服务器：CentOS 6.8
MySQL版本：5.5
找到MySQL错误日志文件位置
解决问题当然是要看问题出在哪里，好在MySQL有自己的错误日志可以供我们分析。那么错误日志在那里呢？ 我们可以用下面的方法找到这个文件的位置：
第一步：登录MySQL终端；
第二步运行下面的命令来查找错误日志的文件位置；
|
|
mysql> show variables like '%log_error%'; |
输出如下：
|
|
+---------------+----------------------------------------+ | Variable_name | Value | +---------------+----------------------------------------+ | log_error | /www/wdlinux/mysql-5.5.27/var/kTWO.err | +---------------+----------------------------------------+ 1 row in set (0.03 sec) |
从结果中我们可以看到，错误日志文件的位置在 /www/wdlinux/mysql-5.5.27/var/kTWO.err
查看并分析MySQL错误日志
错误日志已经找到了，我们打开看一下，通过我的分析，我的这个MySQL运行出错有多处，但是直接导致MySQL宕机的只有一处。日志内容如下：
上面的错误日志是MySQL运行停止的最近一次错误提示。
分析得知，The InnoDB memory heap is disabled这个错误导致了下面一系列的failed和ERROR，最终导致最好的Aborting（异常终止）。这句话的大概意思就是InnoDB内存堆是禁用的。
通过查阅资料发现，MySQL默认的配置使用了操作系统的内存分配器,禁用了InnoDB的内置内存分配器所至。默认的innodb_use_sys_malloc配置是决定内存的分配器，当配置为1时是使用操作系统内存的分配器，当配置为0时使用InnoDB的默认分配器。所以我们只要将这个配置修改为0即可。
解决方案
找到MySQL的配置文件修改innodb_use_sys_malloc配置项为0.
一般的MySQL配置文件位置在/etc/my.cnf
查看配置文件中的配置后发现了一个尴尬的问题，竟然没有找到这个innodb_use_sys_malloc配置项。原来MySQL在版本升级的时候曾经取消了这个配置。但是人工添加上也是可以生效的。
我们直接在[mysqld]下面直接添加innodb_use_sys_malloc=0即可。
然后重启MySQL服务，再次查看日志。
发现之前的错误消失了，没有faild和error了。经过这几天的测试发现，宕机的问题已经解决了，没有再发生。
附上错误日志中的其他几个小问题的解决方案
第一项
在日志中出现了大量的类似警告。
这个警告是在说找不到DNS服务器，在web服务中，很多的服务器都没有DNS服务，所以MySQL提示无法将该IP解析为主机名。
解决方案:在MySQL配置文件中[mysqld]添加skip-name-resolve，这将使MySQL不再通过DNS解析地址。
这个问题的解决还有一个方式，那就是在host文件中添加ip信息，但是这个方案并不可取，ip太多不可能全部添加上。
第二项
上面的错误提示找不到系统的数据表mysql.proxies_priv，这个问题的来源在于我当初升级MySQL版本的时候没有更新系统数据表，导致新版的MySQL数据表不全。
解决方案：执行命令mysql_upgrade -u root -p 输入密码之后将自动更新修复系统数据表。
PS：以上问题都是博主亲自遇到并解决的经验之谈，难免有不到之处，若有不当还请各位指正。若问题依然没有解决可参见《解决MySQL经常停止运行（swap分区设置）》
2022年7月3日 22:01 沙发
后