新手如何调试 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 行，只能挑重点读源码。最近很多群里的人在背八股，没必要，有那时间学着调试下源码，读读多好

原文出处：https://mp.weixin.qq.com/s/lJqb0kMtnAUmqUIWCShkIQ

MySQL 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程。

如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。

临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了。但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量，跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长。而以非 debug 模式运行，则无法修改 validate 变量，想法破灭。

MySQL 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程。

如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。

临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了。但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量，跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长。而以非 debug 模式运行，则无法修改 validate 变量，想法破灭。

---