如何解决mysql的1076

MySQL的1067错误的多种解决方法，下面列举几种方法，以便客户们遇到该错误时可以快速参考解决。

一、安装MYSQL后更改了ROOT的密码后用

net startmysql

启动时我就遇到了这样的问题.使用以下命令后

c:\mysql\bin\mysqladmin-u root -p shutdown

再net start mysql就没有这个错误提示了!

二、MySQL的1067错误

Mysql碰到了 1067 错误

错误信息为：

A system error has occurred.

System error 1067 has occurred.

The process terminated unexpectedly.

可能原因和解决办法是：

1.检查你的Mysql目录有没有给系统的System用户权限。

2.删除掉你的 %WINDOWS%/my.ini 文件。

3.检查你的 my.ini文件配置是否正确设置basedir指向mysql的安装路径

basedir=D:\Program\Tools\mysql

datadir=D:\Program\Tools\mysql\data

三、mysql服务无法启动的解决方法

mysql服务无法启动

无论安装何版本的mysql，在管理工具的服务中启动mysql服务时都会在中途报错

内容为：在 本地计算机 无法启动mysql服务 错误1067：进程意外中止

经过多方求教，得解决方法如下

查找系统(后来验证应该为windows目录)目录下的my.ini文件，编辑内容(如果没有该文件，则新建一个)，至少包含basedir，datadir这两个基本的配置。

[mysqld]

# set basedir to installation path, e.g., c:/mysql

# 设置为MYSQL的安装目录

basedir=D:/www/WebServer/MySQL

# set datadir to location of data directory,

# e.g., c:/mysql/data or d:/mydata/data

# 设置为MYSQL的数据目录

datadir=D:/www/WebServer/MySQL/data

另外，也要注意

[WinMySQLadmin]

Server=D:/www/WebServer/MySQL/bin/mysqld-nt.exe

user=root

password=xxxxxxxx

#以上是设置WinMySQLadmin的配置

[Client]

user=root

password=xxxxxxxx

MySQL 随着版本不停迭代，崩溃的现象越来越少，也越来越隐蔽。

一旦遇到生产环境上的 MySQL 崩溃，就需要保留现场信息，供分析用。虽然 MySQL 的 error log 中会打印部分信息，但对于比较隐蔽的崩溃，往往显得力不从心。

通过开启 *** 作系统级别、放开用户限制、启用 MySQL 参数三个步骤，我们启用了 MySQL 的 coredump 功能，使得 MySQL 崩溃时留下了足够的线索。

对于复杂崩溃的分析，还是需要将 coredump 交给专业的研发工程师手里，或者提交给 MySQL 开发团队。

不过不管是什么场景，能提供一份 coredump，所有技术人员都会感谢你的。

一、无法访问系统资源

MySQL 不能访问启动需要的资源是造成而 MySQL 无法启动的一个常见原因，如：文件，端口等。由于 linux 中用于启动 mysqld 进程的 mysql 用户通常是不能登陆的，可以使用类似下面的命令检查文件的访问权限。

sudo -u mysql touch /var/lib/mysql/b

找出问题后，修改对应文件或目录的权限或属主后通常可以解决问题。但有时 mysql 用户有访问文件和目录的权限，但仍然会被拒绝访问，例如下面这个例子：

mysql>system sudo -u mysql touch /home/mysql/data/a

mysql>create table t1 (

id int primary key,n varchar(10

) data directory

ERROR 1030 (HY000): Got error 168 from storage engine

测试说明 mysql 用户有这个目录的访问权限，但创建文件还是失败，这种情况让很多人困惑，这个时候通常是 mysqld 进程的访问被 linux 的 selinux 或 apparmor 给阻止了，大家可以看到创建的表不是在 mysql 的默认目录下面，因此 selinux 或 apparmor 的 policy 里面没有包含这个目录的访问权限，此时只要对应的修改 policy 就行了，当然把 selinux 或 apparmor 停了也行。

有时虽然对系统资源有访问的权限，但系统资源已经被占用：

mysqld --no-defaults --console --user mysql

2020-11-03T03:36:07.519419Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.19) starting as process 21171

2020-11-03T03:36:07.740347Z 1 [ERROR] [MY-012574] [InnoDB] Unable to lock ./ibdata1 error: 11

这个故障产生的原因是另外一个 mysqld 进程已经启动并占用了对应的文件。

二、参数设置错误

参数设置错误造成 MySQL 无法启动的原因也非常常见，此时先要检查 MySQL 启动时会调用的参数，下面的命令可以查询 MySQL 启动时调用参数文件的顺序：

$ mysqld --verbose --help | grep "Default options " -A 1

Default options are read from the following files in the given order:

/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf

知道了 MySQL 参数文件的调用顺序，我们就可以检查对应的参数文件，找出其中的错误，如果觉得参数文件的可读性不强，可以使用下面的命令显示 mysqld 程序将要调用的参数：

$ mysqld --print-defaults

/usr/sbin/mysqld would have been started with the following arguments:

......

注意这个命令显示完参数后就退出，不会真正运行 mysqld。这个命令和 my_print_defaults mysqld 完全是等价的，只不过后者的显示方式是一行一个参数。

然后开始对可疑的参数进行调试，我个人喜欢加的参数和顺序如下：

1. 在 mysqld 后加上第一个参数 --no-defaults ，这个参数的作用是通知 mysqld 在启动的时候不要读任何参数文件；

2. 第二个参数是 --console，这个参数会把错误信息输出到屏幕上，这个参数带来的一个弊端是所有的信息都输出到屏幕上，让屏幕显得比较乱，但对于我们调试却是很方便的；

3. 第三个参数是 --log-error-verbosity=3，这个参数会显示详细的日志；

4. 然后再在后面加上有把握的参数，可以一次只加一个参数，然后启动 mysqld，采用排除法逐步找出错误的参数。

---