能够看懂MySQL源码是一种怎么样的体验？

首先mysql是c++开发的。 github地址：https://github.com/mysql/mysql-server很多大型软件基本都是c/c++开发的。你会了c/c++基本就具备了领略程序世界的大门的钥匙。 mysql是一个完善的数据库软件。最上层：处理连接，授权认证，安全等 第二层：核心服务功能：查询解析，分析，优化，缓存以及所有内置函数（日期，时间，数据，加密等），存储过程，触发器，视图等。 第三层：存储引擎，存储引擎负责mysql中数据的存储和提取。每个引擎各有优势。服务器通过API与存储引擎进行通信。接口屏蔽了不同引擎的差异，对上层的查询过程透明。 你如果去读它，你基本就可以深入到这些业务点中。然后获取的提升绝对不是一星半点。你会发现开发一个web应用，开发一个中间件如此简单。你获取的是大神级工程师的开发思想，技巧。 举个例子：MVCC ，innodb 隔离性实现的技术。 设计原理很简单，也很巧妙。对数据安全和高并发做了平衡处理。 这个是单纯学习计算机语言，算法数据结构给不了的体验。 当前，你得能看的下去，你有那个恒心。吹牛逼就不要在这里问了？首先，能看懂 MySQL 源码的人物，我感觉肯定在技术上是一位大牛，能够将 C/C++ 语言的 MySQL 源码看懂，肯定也是一位非常有耐心的技术人，能够耐着性子去专研。 如果能够将Mysql源码研究的很透彻的话，我相信出去到大厂找数据库内核开发的岗位时，绝对是一个非常巨大的优势。能看懂 Mysql 的源码，首先第一点需要对 C/C++ 语言的知识点非常的熟悉，因为 MySQL 底层几乎都是 C/C++ 语言写的，比如指针等。 对于 MySQL 源码能够看得的话，我相信在和别人谈论数据库相关的问题时，其实也会更加有专业性和深度，能够快速的理解对方所说的数据库问题。同时，如果对 MySQL 源码有着很深入了解的话，其实对于数据库的相关配置优化等也会掌握的更好，因为你对底层原理了解的很透彻，对于自己做的每一件事情都是有理有据。每个数据库参数是什么含义，为什么要这样设置，背后都有你自己的理解和原因。这对于公司来说，也是非常需要这样的人才。当初我校招的时候，其实准备想投数据库开发相关的岗位，当时其实自己也自学过 MySQL 底层的原理（不过我没有去研究过源码）。 MySQL 最主要的还是底层可插拔式的存储引擎，比如 InnoDB、MYISAM等，重点是 InnoDB存储引擎。学习看 MySQL 源码的话，我建议可以选择其中一个模块开始入手。我刚开始看 《MySQL 技术内幕：InnoDB存储引擎》 这本书的时候，上面讲解的非常多的 MySQL InnoDB 的原理。先从原理知识入手，再去看源码会更加好一些，因为你掌握了整体的代码逻辑方向。说实话直接上手看 MySQL 源码，将会是很难的一件事情。我相信那些能够看懂 MySQL 源码的人，肯定在看源码之前，有一定的技术知识储备。新同学在去研究某一门开源技术组件的源码时，不建议直接上手去看代码，你应该是先去整体了解一下该技术组件的整体原理和框架，源码层则是更加细节方面的实现，你应该带着某一个问题去看，有针对性和目的性的去看源码，这样你的提升才会更加的快速。 我会持续大数据、数据库方面的内容，如果你有任何问题，也欢迎关注私信我，我会认真解答每一个问题。期待您的关注阅读代码，一般都是一件繁复的工作。程序员，只要工作需要、或有足够的时间，都能够胜任阅读代码的工作，特别是数据库这类功能具体的系统。如果软件的功能不确定，阅读起来确实有莫名的困难。年轻时，得到“一套”Z80汇编码，闲来无聊，尝试阅读，数周过去，不得要领。直到在一个忽略了的简单文档的阐述上下文中，意识到代码可能是实现“导d”稳定飞行的侧滚控制系统时，阅读中的问题瞬间都消失了。 拜托啦，我不只能看懂你的SQL，我还可以看懂VB、C++、数据库我也看

Gorm是Go语言开发用的比较多的一个ORM。它的功能比较全：

但是这篇文章中并不会直接看Gorm的源码，我们会先从database/sql分析。原因是Gorm也是基于这个包来封装的一些功能。所以只有先了解了database/sql包才能更加好的理解Gorm源码。

database/sql 其实也是一个对于mysql驱动的上层封装。”github.com/go-sql-driver/mysql”就是一个对于mysql的驱动，database/sql 就是在这个基础上做的基本封装包含连接池的使用

下面这个是最基本的增删改查 *** 作

*** 作分下面几个步骤：

因为Gorm的连接池就是使用database/sql包中的连接池，所以这里我们需要学习一下包里的连接池的源码实现。其实所有连接池最重要的就是连接池对象、获取函数、释放函数下面来看一下database/sql中的连接池。

DB对象

获取方法

释放连接方法

连接池的实现有很多方法，在database/sql包中使用的是chan阻塞 使用map记录等待列表，等到有连接释放的时候再把连接传入等待列表中的chan 不在阻塞返回连接。

之前我们看到的Redigo是使用一个chan 来阻塞，然后释放的时候放入空闲列表，在往这一个chan中传入struct{}{}，让程序继续 获取的时候再从空闲列表中获取。并且使用的是链表的结构来存储空闲列表。

database/sql 是对于mysql驱动的封装，然而Gorm则是对于database/sql的再次封装。让我们可以更加简单的实现对于mysql数据库的 *** 作。

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 的维护者们在后续版本更新时忘记更新文档吧。

---