mysql的错误及调试方法（mysql常见问题）

本文目录一览：

1、新手如何调试 MySQL？看这一篇就够了
2、为什么安装mysql数据库报错
3、mysql启动错误
4、如何轻松解决MYSQL数据库连接过多的错误
5、如何解决MySQL问题

新手如何调试 MySQL？看这一篇就够了

前几天看到姜老师的旧文用 VSCode 编译和调试 MySQL，每个 DBA 都应 get 的小技能[1] , 文末留了一个思考题，如何修改源码，自定义版本，使得 select version() 输出自定义内容

调试过程参考 macOS VSCode 编译调试 MySQL 5.7[2]

内部 Item 对象参考从SQL语句到MySQL内部对象[3]

源码面前没有秘密，建义对 DB 感兴趣的尝试 debug 调试。本文环境为 mac + vscode + lldb

vscode 插件：

mysql 源码：

补丁： MySQL = 8.0.21 需要对 cmake/mysql_version.cmake 文件打补丁 (没有严格测试所有版本)

创建 cmake-build-debug 目录，后续 mysql 编译结果，以及启动后生成的文件都在这里

在 mysql 工程目录下面创建 .vscode/settings.json 文件

内容没啥好说的，都是指定目录及 boost 配置，其中 WITH_DEBUG 打开 debug 模式，会在 /tmp/debug.trace 生成 debug 信息

View - Command Palette - CMake: Configure 执行后生成 cmake 配置

View - Command Palette - CMake: Build 编译生成最终 mysql 相关命令

发现老版本编译很麻烦，各种报错，mysql 5.7 代码量远超过 5.5, 只能硬着头皮看 5.7

首先初始化 my.cnf 配置，简单的就可以，共它均默认

初始化数据文件，非安全模式，调试用

由于用 vscode 接管 mysql, 所以需要配置 .vscode/launch.json

然后点击 run and debug mysqld

mysql 启动，看到输出日志无异常，此时可以用 mysql-client 连接

首先在 sql_parser.cc:5435 处打断点

mysql_parse 是 sql 处理的入口，至于 tcp connection 连接先可以忽略

执行上述 sql 自动跳转到断点处， Step Into , Step Over , Step Out 这些调试熟悉下即可

接下来分别调用主要函数： mysql_execute_command , execute_sqlcom_select , handle_query , select-join-exec() , Query_result_send::send_data , Item::send , Item_string:val_str , Protocol_text::store , net_send_ok

启动 mysql 时 init_common_variables 会初始化一堆变量，其中会调用 set_server_version 生成版本信息，修改这个就可以

看好条件编译的是哪块，修改即可，重新 CMake: Build 编译再运行

这里不做过深分析，简单讲

sql_yacc.cc 函数 PTI_function_call_generic_ident_sys 解析 sql, 识别出 version() 是一个函数调用

find_native_function_builder 查找 hash 表，找到对应 version 函数注册的单例工厂函数

mysql 启动时调用 item_create_init 将这些函数 builder 注册到 hash 表 native_functions_hash

MySQL 代码太庞大，5.1 大约 100w 行，5.5 130w 行，5.7 以后 330w 行，只能挑重点读源码。最近很多群里的人在背八股，没必要，有那时间学着调试下源码，读读多好

原文出处：

为什么安装mysql数据库报错

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

我的下载的是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-winx64data。问题解决。

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

mysql启动错误

一、无法访问系统资源

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，采用排除法逐步找出错误的参数。

如何轻松解决MYSQL数据库连接过多的错误

1、MySQL数据库系统允许的最大可连接数max_connections。这个参数是可以设置的。如果不设置，默认是100。最大是16384。

2、数据库当前的连接线程数threads_connected。这是动态变化的。

查看max_connections、max_connections的办法见后。

如果

threads_connected

max_connections

时，数据库系统就不能提供更多的连接数了，这时，如果程序还想新建连接线程，数据库系统就会拒绝，如果程序没做太多的错误处理，就会出现类似强坛的报错信息。

因为创建和销毁数据库的连接，都会消耗系统的资源。而且为了避免在同一时间同时打开过多的连接线程，现在编程一般都使用所谓数据库连接池技术。

但数据库连接池技术，并不能避免程序错误导致连接资源消耗殆尽。

这种情况通常发生在程序未能及时释放数据库连接资源或其他原因造成数据库连接资源不能释放，但强坛系统估计不会发生这种低级的编程错误。

该错误的简便的检查办法是，在刷新强坛页面时，不断监视threads_connected的变化。如果max_connections足够大，而

threads_connected值不断增加以至达到max_connections，那么，就应该检查程序了。当然，如果采用数据库连接池技术，

threads_connected增长到数据库连接池的最大连接线程数时，就不再增长了。

从强坛出错的情况看，更大的可能性是数据库系统没能进行适当地配置。下面提出一点建议。供参考

让你们的工程师把MySQL的最大允许连接数从默认的100调成32000。这就不会老出现连接过多的问题了。

查看max_connections

进入MySQL，用命令：

show

variables

查看数据库最大可连接数的变量值：

max_connections

查看threads_connected

进入MySQL，用命令：

show

status

查看当前活动的连接线程变量值：

threads_connected

设置max_connections

设置办法是在my.cnf文件中，添加下面的最后红色的一行：

[mysqld]

port=3306

#socket=MySQL

skip-l

如何解决MySQL问题

1、情况一：MySQL的错误日志文件（安装目录MYOAdata5机器名.err）会记录如下内容：

InnoDB: Reading tablespace information from the .ibd files...

InnoDB: Error: trying to add tablespace 460 of name '.td_oaflow_data_35.ibd'

InnoDB: to the tablespace memory cache, but tablespace

InnoDB: 460 of name '.td_oaexam_data.ibd' already exists in the tablespace

解决方法：

1）剪切出安装目录MYOAdata5TD_OA的flow_data_35.ibd和flow_data_35.frm两个文件；

2）启动MySQL5_OA服务，使用备份的flow_data_35.sql导入到TD_OA库中。如果提示flow_data_35表已经存在不能导入，则继续按后续步骤执行；

3）在data5下手动建立tmp目录；

4）使用MySQL管理工具或MySQL命令行程序在tmp下建立名称为flow_data_35的表（包含一个字段即可）；

5）将tmp下的flow_data_35.frm和flow_data_35.ibd拷贝到安装目录MYOAdata5TD_OA目录下；

6）在MySQL管理工具或MySQL命令行程序中，进入TD_OA库，使用“drop table flow_data_35;”命令清除公共表空间中残留的flow_data_35表的相关信息；

7）进入tmp库，删掉flow_data_35表；

8）使用备份的flow_data_35.sql导入到TD_OA库中；

9）如果还有其他表存在该问题，可重复执行4至8步骤。

2、情况二：MySQL的错误日志文件（安装目录MYOAdata5机器名.err）会记录如下内容：

130409 15:54:31 [Note] Plugin 'FEDERATED' is disabled.

130409 15:54:31 InnoDB: The InnoDB memory heap is disabled

130409 15:54:31 InnoDB: Mutexes and rw_locks use Windows interlocked functions

130409 15:54:31 InnoDB: Compressed tables use zlib 1.2.3

130409 15:54:32 InnoDB: Initializing buffer pool, size = 1023.0M

InnoDB: VirtualAlloc(1086849024 bytes) failed; Windows error 8

130409 15:54:32 InnoDB: Completed initialization of buffer pool

130409 15:54:32 InnoDB: Fatal error: cannot allocate memory for the buffer pool

130409 15:54:32 [ERROR] Plugin 'InnoDB' init function returned error.

130409 15:54:32 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.

130409 15:54:32 [ERROR] Unknown/unsupported storage engine: Innodb

130409 15:54:32 [ERROR] Aborting

解决方法：

此情况出现的原因是myoamysql5my.ini中innodb_buffer_pool_size的值太大，OA服务器操作系统不支持所致。改小后再启动mysql5_OA服务即可，一般保持和数据库大小一致。数据库大小即是myoa/data5的大小。

3、情况三：mysql服务启动不了，事件查看器中显示：The syntax

'--log-slow-queries' is deprecated and will be removed in a future

release. Please use '--slow-query-log'/'--slow-query-log-file' instead.

解决方法：安装目录MYOAdata5下的ibdata1、ib_logfile0、ib_logfile1文件属性被设置为只读导致，取消只读控制，重启mysql5_OA服务即可。

4、情况四：MySQL的错误日志文件（data5机器名.err）会记录如下内容：InnoDB: No valid checkpoint found.

解决方法：此问题找不到检查点，数据库是无效的，此种情况，只能用热备份数据恢复。

5、以上四种情况，是2013版OA系统目前比较常见的mysql服务启动不了的现象和解决办法，大家可作参考，其他情况的话，再具体分析处理。

6、分析思路总结：遇到mysql5_OA服务启动不了的情况，首先查看myoadata5下的错误日志文件，根据日志中的具体内容进行具体分析。

7、2013版MYSQL服务启动不了（可以尝试强制启动mysql服务）方法如下：

1)打开MYOAmysql5my.ini，去掉innodb_force_recovery=1前边的注释。

2)启动MySQL5_OA服务，此时MySQL处于只读状态，可以导出，不可写入。如果仍不能启动，可以尝试将innodb_force_recovery修改为2、3、4、5、6等，直到可以启动为止。

3)使用MySQL管理工具，将TD_OA等相关的数据库导出为SQL文件。

4)停止MySQL5_OA服务，删除TD_OA下的所有文件、ibdata1、ib_logfile0、ib_logfile1等文件。

5）打开MYOAmysql5my.ini，在innodb_force_recovery=1前边加上#号，将该项注释掉。