1. 为什么要写专栏？
我还在做业务系统研发的时候，有一段时间，系统不稳定，慢 SQL 很多。我们团队花了很长时间持续优化 SQL。
我们有一个表格，从慢查询日志里整理出了很多慢 SQL。其中一些 SQL，按照我们的理解，根本不应该出现在表格里，但是它们却经常出现。
我对这些 SQL 印象深刻，它们是：
- update xxx set xxx where id = xxx
- commit
- truncate table xxx
以我们当时对 MySQL 有限的了解，这些 SQL 执行起来都很快，不应该出现在慢查询日志里。
我们不了解这些 SQL 执行过程中都干了些什么，不理解它们是怎么执行的，想要优化也就无处下手了。
随着逐渐深入研究 MySQL 源码，我已经能解释这些 SQL 为什么会出现在慢查询日志里了。
对 SQL 执行过程不了解，这是我曾经的痛点，相信也是很多业务系统研发和 DBA 的痛点。
我投入了很多时间研究 MySQL 源码，正在逐步解决这些痛点。
现在，我把这些内容写出来，分享给需要的各位读者，希望也能帮助大家解决工作过程中遇到的痛点。
2. 专栏包含哪些内容？
我正在研究 InnoDB 的几个模块，专栏内容都来源于这些模块：
- 事务
- 锁（InnoDB 的记录锁和表锁，不包含 server 层的元数据锁）
- Redo
- Undo
- MVCC
3. 专栏内容怎么呈现？
关于专栏的内容，我考虑过 3 种呈现方式。
① 源码详细分析。
以讲解源码为主，在讲解源码的过程中，顺便介绍原理。
之前写过几篇 MySQL 功能实现的源码分析文章、也结合源码写了几篇分析线上问题的文章，有读者反馈看不懂源码，对于这样的文章，他们会直接跳过源码，只看原理介绍。
② 源码关键节点 + 原理介绍：
用 SQL 执行过程中经历的关键节点的源码把原理串起来。
这种方式按照 SQL 的执行流程，通过源码关键节点来介绍原理，文章内容可能会有点碎片化，不好抽象成介绍原理且逻辑流畅的文章。
③ 原理介绍：
这种方式以讲解原理为主，在需要的时候会加上一点点源码作为辅助，方便理解。我之前写的公众号文章主要以这种方式呈现。
考虑到目标读者是想了解 MySQL 底层原理的业务系统研发和 DBA，最终还是确定以第 ③ 种方式（原理介绍）来写专栏的系列文章。
4. 聊聊心路历程
这个专栏从虚无中诞生，算是个结果。凡事有果必有因，我们再来聊聊是什么因结出了这个果。
细算起来，我已经 4 个月没写文章了，停更这么久，并不是放弃了写文章，而是把重点转移到研究 MySQL 源码上了。
这段暂停时期，既是意料之外，也是顺理成章。
意料之外在于，我也没有想到 8 月份写完《InnoDB 全表扫描和全主键扫描一样吗？》这篇文章之后，就会停更，并且一停就是 4 个月。
顺理成章在于，8 月份之前已经有一段时间感觉到写文章吃力了，停更也是迟早的事。
我思考过感到吃力的原因：
因为我的目标是每周发一篇文章，一周之内我需要找到一个文章主题、并且研究这个主题相关的代码、写成文章。
其中最费时间的就是研究代码了，这通常会占据我一周中大部分用于写文章的业余时间。
研究代码占用了大量时间，再加上写文章，这让我感到越来越吃力。
到 8 月份写完前面提到的那篇文章之后，有一些复杂的感觉交织在一起：如释重负、元气耗尽、迷茫，让我没有动力继续写下一篇文章了。
这些复杂的感觉交织的过程中，我也在思考接下来要怎么办？写文章这件事怎么才能做到更轻松更持久？
为此，我先总结了一下我写文章的几个阶段。
第 1 阶段：
刚开始研究 MySQL 源码的时候，我也会写文章，发到我的博客上。
写完文章之后还会给同事看，同事说看不懂。
当时我也很郁闷，我很用心的花了很长时间写的文章，同事看不懂。
虽然郁闷，但日子还要继续过下去，还得继续研究源码、继续写文章。
第 2 阶段：
就这样一边郁闷，一边研究代码，一边写文章，时间就过去了几个月。
某一天，我又写了一篇文章，发给同事看。同事看了之后，给出了很不错的评价。
这让理解了从读者的角度来看，什么样的文章算是好文章。
接下来的事就顺理成章了：注册公众号、继续研究源码、继续写文章。
这里要郑重感谢一下我前面提到同事 @李亮，在前期给了我很重要的帮助。
第 3 阶段：
全职研究代码，基本上一周发一篇文章。
这个阶段虽然没有收入，但是每天动力很足，有一种感觉就是日子过的红红火火。
这叫什么？这就叫穷开心！
第 4 阶段：
我上班了，只能利用业余时间研究代码。
想要像之前那样写长文章，还每周发一篇，已经不太可能实现了。
这个阶段的主旋律就是围绕问题研究代码、写文章，同事和读者有时候会问我一些问题，我就围绕问题去研究代码，写成文章。
开始一段时间，依然乐此不疲。虽然吃力，也还基本能应付过来。
时间一长，吃力感越来越明显了，持续到 8 月份，写文章之事就由于不堪重负暂时停了下来。
我还想继续写文章，但需要找到一种相对来说更轻松的方式，这样才能可持续发展。
经过一番思考之后，我决定把写文章的事放一放，先专心研究一段时间代码，把 InnoDB 几个主要模块的细节都研究一遍，再接着写文章。
时间飞快，转眼已是四个月，从秋高气爽到白雪皑皑，我恢复了元气，又可以继续写文章了。
重生的文章，以系列的形式连载，需要新的载体，于是就有了这个专栏。
接下来，就要进入第 5 阶段了。这个专栏和第 5 阶段相伴而生，我在此许下一个愿望：希望专栏和第 5 阶段都能够持续的很久~很久~，和大家一起奔赴未来！
5. 我们一起奔赴未来！
《MySQL 核心模块揭秘》 专栏预期每周发布一篇文章，持续一年左右。
接下来的一年，我们一起 探索 InnoDB 事务、锁、Redo、Undo、MVCC 的底层原理，看看 MySQL 运行时都干了什么？
风起于青萍之末，浪成于微澜之间。下一期（专栏的第 1 篇正式文章）我们会聊聊 InnoDB 事务的起源：事务池和事务池管理器。
更多技术文章，请访问：https://opensource.actionsky.com/
关于 SQLE
SQLE 是一款全方位的 SQL 质量管理平台，覆盖开发至生产环境的 SQL 审核和管理。支持主流的开源、商业、国产数据库，为开发和运维提供流程自动化能力，提升上线效率，提高数据质量。
SQLE 获取
| 类型 | 地址 |
|---|---|
| 版本库 | https://github.com/actiontech/sqle |
| 文档 | https://actiontech.github.io/sqle-docs/ |
| 发布信息 | https://github.com/actiontech/sqle/releases |
| 数据审核插件开发文档 | https://actiontech.github.io/sqle-docs/docs/dev-manual/plugins/howtouse |
