如何查看mySQL的源代码

给你个过来人的建议。两个方式入手。

1、利用他。尽可能从大模块开始，用你的代码，去调用他。这是从功能特性角度，去理解各个模块的作用。这非常容易加深你对应用它的理解。

2、在代码中插入LOG，检测代码运行流程。

如果你只是静态的看代码，这个不现实的。

如果你想看一部分代码。首先你要想办法让这套代码RUN起来，如果你使用任何方式都无法让这段代码运行，我只能说，这段代码没有存在价值。为什么在里面，当然更大的可能是，你没找到开启它的方法。

动态分析法，是门学问。包括对运行态才出现BUG的系统进行DEBUG，当然不是GDB或者VC的F5模式。不过貌似学校没有这类教学。很工程的东西。我也只是经验所得。没有系统的理论化。

例如一套系统，你在不改代码的情况下，要能找到问题。甚至不能加LOG代码，只能通过反馈判断。不是不可能的。甚至有时必须这么做。

用vs code 就可以了。

Visual Studio Code

Visual Studio Code（简称VS Code）是由微软开发的，同时支持Windows、Linux和macOS *** 作系统的开源文本编辑器。它支持调试，内置了Git 版本控制功能，同时也具有开发环境功能，例如代码补全（类似于IntelliSense）、代码片段、代码重构等。该编辑器支持用户自定义配置，例如改变主题颜色、键盘快捷方式、编辑器属性和其他参数，还支持扩展程序并在编辑器中内置了扩展程序管理的功能。

安装LLDB

LLDB是LLVM编译器的一部分，推荐使用Homebrew安装LLVM工具集，不建议使用系统自带的LLDB，安装前必须先创建证书否则无法安装，步骤如下：

创建完成后，开始安装LLVM

brew install llvm --with-python@2 --with-lldb

安装插件

VS Code自带有debug功能，这里我推荐使用LLDB Debugger插件。

接下来，为项目配置调试参数。

配置调试参数

使用VS Code打开MySQL源码目录，在侧边栏选择debug栏目，添加配置，program输入需要调试的程序路径，这里选择你编译好的mysqld路径，args输入程序启动所需的参数，通常会指定mysqld的配置文件。这样就配置好了，是不是很简单。

启动调试

点击启动按钮，启动后如果没有设置断点会mysqld会正常启动，如果触发了断点会如下图显示。

整个调试窗口基本分为六部分，所有的调试 *** 作都在这里完成:

1: 显示变量信息

2: 设置重点关注的变量

3: 显示调用栈信息

4: 设置断点信息，在代码行号前也可以设置断点

5: 代码显示区域，上方是调试按钮，包括 continue/stepover/step in/step out/restart/stop

6: 调试终端输入输出区

断点设置

在代码行号前点击即可在该行为设置断点，也可以根据条件设置断点。以设置ConditionalBreakpoint为例，当程序启动后会按照你设置的条件表达式判断是否触发断点。

Conditional Breakpoint这种方式用在目标变量达到某条件时触发断点，其余则跳过继续执行。比如：设置变量等于目标表名时触发断点，其余表则跳过，相对函数名断点省去很多手工跳过 *** 作。

远程调试

假如你想调试远程Linux服务器上的MySQL上面的方法就不合适了，这时需要远程调试。lldb和gdb都支持远程调试，这里以lldb为例。

需要先在远程主机上安装lldb，使用yum安装，源地址在这里http://mirror.centos.org/centos/7/sclo/x86_64/rh

remote$ yum install -y llvm-toolset-7

安装完成后，启动lldb-server

remote$ /opt/rh/llvm-toolset-7/root/usr/bin/lldb-serverplatform --listen "*:9191" --server

接下来，在VS Code调试界面中新增配置项。

{

"type": "lldb",

"request": "attach",

"name": "Remote attach",

"program": "~/mysql5626/usr/local/mysql/bin/mysqld",

"pid":"<target_pid>",

"initCommands": [

"platform select remote-linux",

"platform connect connect://<remote_host>:9191"

],

"sourceMap": {

"/export/home/pb2/build/sb_0-15908961-1436910670.17/mysql-5.6.26": "/Users/hongbin/workbench/mysql-server"

}

},

program: 本机也要拷贝一份目标程序，加载

pid: 填写远程主机的mysqld进程id

sourceMap: 填写mysqld编译的代码路径与本机代码库路径的映射，这样调试时代码才可以和程序关联在一起看

注意：记得调试前将代码切换到与目标程序版本一致的branch

MYSQL_OPT_READ_TIMEOUT 是 MySQL c api 客户端中用来设置读取超时时间的参数。在 MySQL 的官方文档中，该参数的描述是这样的：

MYSQL_OPT_READ_TIMEOUT (argument type: unsigned int *)The timeout in seconds for each attempt to read from the server. There are retries if necessary, so the total effective timeout value is three times the option value. You can set the value so that a lost connection can be detected earlier than the TCP/IPClose_Wait_Timeout value of 10 minutes.

也就是说在需要的时候，实际的超时时间会是设定值的 3 倍。但是实际测试后发现实际的超时时间和设置的超时时间一致。

而具体什么时候发生三倍超时，在文档中没有找到。所以对 MySQL 5.7.20 的源码进行了一些分析。

使用 GDB 调试代码找了实际与 mysql server 通信的代码，如下：

请点击输入图片描述

其中 vio_read() 函数中，使用 recv 和 poll 来读取报文和做读取超时。net_should_retry() 函数只有在发生 EINTR 时才会返回 true。从这段代码来看是符合测试结果的，并没有对读取进行三次重试。只有在读取 *** 作被系统中断打断时才会重试，但是这个重试并没有次数限制。

从上面代码的分析可以看出，代码的逻辑和文档的描述不符。于是在一顿搜索后，找到了一个 MySQL 的 BUG(Bug #31163)。该 BUG 报告了在 MySQL 5.0 中，MySQL c api 读取的实际超时时间是设置的三倍，与现有文档描述相符。于是对 MySQL 5.0.96 的代码又进行分析。

同样使用 GDB 找到了通信部分的代码。这次找到了重试三次的代码，如下：

请点击输入图片描述

这个版本的 MySQL api 的读写超时是直接使用的 setsockopt 设置的。第一次循环，在 A 点发生了第一次超时（虽然注释写的非阻塞，但是客户端的连接始终是阻塞模式的）。然后在 B 点将该 socket 设置为阻塞模式，C 点这里重置 retry 次数。由于设置了 alarm 第二次以后的循环会直接进入 D 点的这个分支，并且判断循环次数。作为客户端时net->retry_count 始终是 1，所以重试了两次，共计进行了 3 次 vioread 后从 E 点退出函数。

由上面的分析可知，MySQL 文档对于该参数的描述已经过时，现在的 MYSQL_OPT_READ_TIMEOUT 并不会出现三倍超时的问题。而 Bug #31163 中的处理结果也是将文档中该参数的描述更新为实际读取超时时间是设定时间的三倍。也许是 MySQL 的维护者们在后续版本更新时忘记更新文档吧。

---