本文目录一览：
- 1、mysql内核源码是什么语言写的
- 2、mysql连接超时怎么处理
- 3、如何查看mySQL的源代码
mysql内核源码是什么语言写的
mysql的内存管理庞大而先进，这在mem0pool.c文件的开头注释中都有说明，粗略的可以分成四部分，包含9大块：
buffer pool,
parsed andoptimized SQL statements,
data dictionarycache,
log buffer,
locks for eachtransaction,
hash table forthe adaptive index,
state andbuffers for each SQL query currently being executed,
session foreach user, and
stack for eachOS thread.
9大块通过4部分进行管理
A solution tothe memory management:
1. the bufferpool size is set separately;
2. log buffersize is set separately;
3. the commonpool size for all the other entries, except 8, is set separately.
也就是缓冲池，redo日志缓冲，普通池和8（用户session信息，可看做一部分）
redo日志缓冲由redo部分单独管理，bufferpool也就是缓冲池是一个复杂的部分，内容很多，普通池上面说了，除了8，和1,2.其余的都归它管。上面这个结构就是mysql内存子系统的完整图景。
所以说是c和c++写的
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 的维护者们在后续版本更新时忘记更新文档吧。
如何查看mySQL的源代码
给你个过来人的建议。两个方式入手。
1、利用他。尽可能从大模块开始，用你的代码，去调用他。这是从功能特性角度，去理解各个模块的作用。这非常容易加深你对应用它的理解。
2、在代码中插入LOG，检测代码运行流程。
如果你只是静态的看代码，这个不现实的。
如果你想看一部分代码。首先你要想办法让这套代码RUN起来，如果你使用任何方式都无法让这段代码运行，我只能说，这段代码没有存在价值。为什么在里面，当然更大的可能是，你没找到开启它的方法。
动态分析法，是门学问。包括对运行态才出现BUG的系统进行DEBUG，当然不是GDB或者VC的F5模式。不过貌似学校没有这类教学。很工程的东西。我也只是经验所得。没有系统的理论化。
例如一套系统，你在不改代码的情况下，要能找到问题。甚至不能加LOG代码，只能通过反馈判断。不是不可能的。甚至有时必须这么做。