MySQL 核心模块揭秘 |《发刊词》

发布时间:2023年12月28日

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
文章来源:https://blog.csdn.net/ActionTech/article/details/135262008
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。