mysql怎么会报错 mysql错误处理

为什么安装mysql会出现start service错误？

一般是因为多次安装没有卸载干净，只要把文件夹，服务，注册表都卸载干净，再次安装就可以了。

成都创新互联网站建设服务商，为中小企业提供成都网站制作、成都网站建设、外贸营销网站建设服务，网站设计，绵阳服务器托管等一站式综合服务型公司，专业打造企业形象网站，让您在众多竞争对手中脱颖而出成都创新互联。

解决方案：使 用services.msc打开服务窗口，查看MySQL service是否已经存在。如已经存在并已启动，则先停止该服务，然后到注册表("HKEY_LOCAL_MACHINE/SYSTEM /CurrentControlSet/Services")中删除对应服务，并使用命令sc delete MySQL,然后继续进行安装，就能成功。

不知道你安装的是MYsql哪个版本，是否是5.0，首先告诉你，数据库只能装一次，如果你在你第一次没有装成功的情况下，你必须要卸载干净才 能装得上，不然会出现很多问题导致你不会安装成功，至于卸载，个人觉得手动卸载其实是最干净利落的，控制面板删除，然后regedit里面Ctrl+F搜 索mysql，但凡是跟这个相关的一切都给他删除掉。

C:\DocumentandSettings\Administrator\ApplicationData(C:\Users\YongHeng\AppData\Roaming/C:\Users\YongHeng\AppData\LocalLow/C:\Users\YongHeng\AppData\Local)中删除MYSQL相关的目标信息.

为什么mysqld启动报错

当安装好mysql后，启动：/etc/init.d/mysql start 却报了个错：Starting MySQL..Manager of pid-file quit without updating f[失败]) 。下面是我对报错的解决方法总结，我在许多环境下安装过mysql,由于多种原因会报各种错误，现在做个总结以作备查。

一、查看报错日志

报错日志是我们解决问题的方向灯，没有方向灯我们就没了方向。我有次安装时报错日志里就有这样的错误：

/usr/local/mysql/bin/mysqld: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory。很明显是缺少了库文件 libstdc++.so.5 。这时我们搜索和libstdc相关的包安装即可。

二、也许是selinux惹的祸

如果是centos系统，默认会开启selinux，这个时候可以先关闭它，打开/etc/selinux/config，把SELINUX=enforcing改为SELINUX=disabled后存盘退出重启机器试试。

三、残余数据

也有可能是第二次在机器上安装mysql，有残余数据影响了服务的启动，去mysql的数据目录/data看看，如果存在mysql-bin.index，就赶快把它删除掉吧，它就是罪魁祸首了。

四、确定数据目录的权限

数据目录一般是prefix/data，检查一下它的归属，如果不是mysql所有者，一般安装mysql时都会创建mysql的用户和组的，这时要修改一下用户和组：

chown -R mysql:mysql /var/data

五、没有指定数据目录

mysql在启动时没有指定配置文件时会使用/etc/my.cnf配置文件，请打开这个文件查看在[mysqld]节下有没有指定数据目录(datadir)。如果没有请在[mysqld]下设置这一行：

datadir =/usr/local/mysql/data

六、还有mysql进程在跑着

如果这是第二次在机器上安装mysql就极有可能会出现这种情况的，这时系统上很有可能还有mysql进程在运行着。可以执行下列命令查看：

ps -ef | grep mysql

如果出现的结果不止一行的就赶快把它kill掉吧。

七、skip-federated字段在作祟

可以检查一下/etc/my.cnf文件中有没有没被注释掉的skip-federated字段，如果有就立即注释掉吧。

八、出错日志目录不存在

也有可能你现在还不知道mysql的出错日志在哪里吧？这时你可以执行命令查看：

cd mysql/bin

./mysql_safe

这时一定会报错的， 并在错误中显示将错误写在某某目录的某某文件里了，这里检查一下这个目录和文件是否存在，在的话就按日志指示解决，如果没有的话就要创建目录并修改权限和归属了。一般会是/var/lib/mysql/mysql.error，注意mysql.error不用创建的。

cd /var/lib

mkdir mysql

chmod 777 mysql

chown mysql:mysql mysql

为什么mysql创建表总报错？

出现1064一般都属于语法错误的情况。把表名的单引号和把tinyint的长度去掉。

数据库的语言由GB2312改成 UTP-8就好了。不行就改为GB2312试试，这个错误是因为数据库语言格式与客户端编码格式不一致到导致的

MySQL 是一个关系型数据库，由瑞典 MySQL AB 公司开发，目前属于 Oracle 旗下公司。MySQL 最流行的关系型数据库管理系统，在 WEB 应用方面 MySQL 是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。

MySQL 是一种关联数据库管理系统，关联数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。MySQL 所使用的 SQL 语言是用于访问数据库的最常用标准化语言。MySQL 软件采用了双授权政策(本词条"授权政策")，它分为社区版和商业版，由于其体积小、速度快、总体拥有成本低。

mysql5.6.23报错1067

我遇到同样的错误，折腾了好久才摸索出来。网上的解决办法都试过了，没有确实可行的。最终总结出来，终于解决了。

我的下载的是mysql-5.7.9绿色版出的问题。最终解决过程供你参考：

1、下载的mysql-5.7.9，出现你的问题。试了各种办法无法解决。有网友说mysql-5.7.9版本有问题。我改下载了5.6.27版本，尝试不成功。但报错变为：无法启动mysql服务,发生错误1067。解决办法：my.ini 添加 tmpdir = D:\mysql-5.6.27-winx64\data。问题解决。

2、后来我对比了mysql-5.7.9与5.6.27，发现mysql-5.7.9-winx64没有data目录，mysql-5.6.27-winx64\data\mysql，存了不少数据文件。原来调试5.7.9的版本时，记得日志报告一直有mysql.user、mysql.plugin不存在的提示。（原以为这些文件会自动生成）。后来把这个mysql-5.6.27-winx64\data下的mysql文件夹整个复制到5.7.9版本中的同目录下。问题解决。

启动mysql服务器报错的原因是什么？

一般情况下mysql的启动错误还是很容易排查的，但是今天我们就来说一下不一般的情况。拿到一台服务器，安装完mysql后进行启动，启动错误如下：

有同学会说，哥们儿你是不是buffer pool设置太大了，设置了96G内存。这明显提示无法分配内存嘛。如果真是这样也就不在这里进行分享了，哈哈。

我的服务器内存是128G。如下图：

服务器内存使用情况：

那么问题来了，既然还剩如此多的内存，为什么提示无法分配内存？？。各位童鞋怎么看？

1. 首先想到会不会是有几条内存坏了？于是运维的同学进行了检查，给我的反馈是硬件一切正常。

2. 把mysql配置参数又检查了一遍，没有发现什么问题，线上一直就是使用这些参数。

3. 又把文件拷贝到另外一台机器，，另外一台服务器可以正常启动（2台机器硬件配置一致）。

那么如果排除硬件问题，mysql配置问题，那么剩下的就只有操作系统的内核参数配置了。于是把两台服务器进行了对比，最终发现了一个内核参数不一致。

复制代码代码如下:

vm.overcommit_memory

mysql启动正常的服务器改参数的值是0，而mysql启动错误的这台服务器该值是2。

那么问题来了，这个参数到底是什么鬼？竟然会让mysql分配内存失败，最后导致无法启动。经过查询资料知道了vm.overcommit_memory是什么鬼。

vm.overcommit_memory

默认值为：0

从内核文档里得知，该参数有三个值，分别是：

0：当用户空间请求更多的的内存时，内核尝试估算出剩余可用的内存。

1：当设这个参数值为1时，内核允许超量使用内存直到用完为止，主要用于科学计算.

2：当设这个参数值为2时，内核会使用一个决不过量使用内存的算法，即系统整个内存地址空间不能超过swap+50%的RAM值，50%参数的设定是在overcommit_ratio中设定。

vm.overcommit_ratio

默认值为：50

这个参数值只有在vm.overcommit_memory=2的情况下，这个参数才会生效。

那么我们来看一下总的内存地址不能超过多少。其实是可以直接查看的。

[root@yayundeng 3306]# cat /proc/meminfo |grep -i commit

CommitLimit:  70144396 kB

Committed_AS:   135196 kB

[root@yayundeng 3306]#

通过查看可以得知在70G的样子。那么这个是如何计算的呢？这个就是上面提到的一个公式。swap+50%的RAM值，50%参数的设定是在overcommit_ratio中设定。

总虚拟内存 = 可用物理内存 × 百分比 + 交换分区

[root@yayundeng 3306]# cat /proc/meminfo | grep MemTotal

MemTotal:    132096808 kB

[root@yayundeng 3306]#

[root@yayundeng 3306]# free -k

total    used    free   shared  buffers   cached

Mem:   132096808  1583944 130512864     0   10240   133220

-/+ buffers/cache:  1440484 130656324

Swap:   4095992     0  4095992

[root@yayundeng 3306]# cat /proc/sys/vm/overcommit_ratio

50

[root@yayundeng 3306]#

总虚拟内存=132096808 * 50% + 4095992= 70144396 kB

那么最后的结果就是buffer pool不能超过70144396 kB - 135196 kB=70009200 KB=66G。实际上经过测试，buffer pool只能设置57G。

最后在看看总虚拟内存情况：

CommitLimit：最大可用虚拟内存

Committed_AS：已使用虚拟内存

[root@yayundeng 3306]# cat /proc/meminfo |grep -i commit

CommitLimit:  70144396 kB

Committed_AS:  65539208 kB

那么如果把内核参数vm.overcommit_memory恢复为默认值0，那么将不会受到约束。

复制代码代码如下:

echo 0 /proc/sys/vm/overcommit_memory

参考资料：

总结：

说了这么多，那么为什么要修改内核参数vm.overcommit_memory的值呢？这个是因为这台服务器之前跑过GreenPlum数据库，拿到我手上的时候没有进行重装系统，那么还是建议如果拿到的机器之前跑过其他的业务，那么保险的方法还是重装一下系统，然后再部署自己的业务，不然真的会出现莫名其妙的问题。