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 種呈現方式。
① 源碼詳細分析。<br />以講解源碼爲主，在講解源碼的過程中，順便介紹原理。
之前寫過幾篇 MySQL 功能實現的源碼分析文章、也結合源碼寫了幾篇分析線上問題的文章，有讀者反饋看不懂源碼，對於這樣的文章，他們會直接跳過源碼，只看原理介紹。
② 源碼關鍵節點 + 原理介紹：<br />用 SQL 執行過程中經歷的關鍵節點的源碼把原理串起來。
這種方式按照 SQL 的執行流程，通過源碼關鍵節點來介紹原理，文章內容可能會有點碎片化，不好抽象成介紹原理且邏輯流暢的文章。
③ 原理介紹：<br />這種方式以講解原理爲主，在需要的時候會加上一點點源碼作爲輔助，方便理解。我之前寫的公衆號文章主要以這種方式呈現。
考慮到目標讀者是想了解 MySQL 底層原理的業務系統研發和 DBA，最終還是確定以第 ③ 種方式（原理介紹）來寫專欄的系列文章。
4. 聊聊心路歷程
這個專欄從虛無中誕生，算是個結果。凡事有果必有因，我們再來聊聊是什麼因結出了這個果。
細算起來，我已經 4 個月沒寫文章了，停更這麼久，並不是放棄了寫文章，而是把重點轉移到研究 MySQL 源碼上了。
這段暫停時期，既是意料之外，也是順理成章。
意料之外在於，我也沒有想到 8 月份寫完《InnoDB 全表掃描和全主鍵掃描一樣嗎？》這篇文章之後，就會停更，並且一停就是 4 個月。
順理成章在於，8 月份之前已經有一段時間感覺到寫文章喫力了，停更也是遲早的事。
我思考過感到喫力的原因：<br />因爲我的目標是每週發一篇文章，一週之內我需要找到一個文章主題、並且研究這個主題相關的代碼、寫成文章。
其中最費時間的就是研究代碼了，這通常會佔據我一週中大部分用於寫文章的業餘時間。
研究代碼佔用了大量時間，再加上寫文章，這讓我感到越來越喫力。
到 8 月份寫完前面提到的那篇文章之後，有一些複雜的感覺交織在一起：如釋重負、元氣耗盡、迷茫，讓我沒有動力繼續寫下一篇文章了。
這些複雜的感覺交織的過程中，我也在思考接下來要怎麼辦？寫文章這件事怎麼才能做到更輕鬆更持久？
爲此，我先總結了一下我寫文章的幾個階段。
第 1 階段：<br />剛開始研究 MySQL 源碼的時候，我也會寫文章，發到我的博客上。
寫完文章之後還會給同事看，同事說看不懂。
當時我也很鬱悶，我很用心的花了很長時間寫的文章，同事看不懂。
雖然鬱悶，但日子還要繼續過下去，還得繼續研究源碼、繼續寫文章。
第 2 階段：<br />就這樣一邊鬱悶，一邊研究代碼，一邊寫文章，時間就過去了幾個月。
某一天，我又寫了一篇文章，發給同事看。同事看了之後，給出了很不錯的評價。
這讓理解了從讀者的角度來看，什麼樣的文章算是好文章。
接下來的事就順理成章了：註冊公衆號、繼續研究源碼、繼續寫文章。
這裏要鄭重感謝一下我前面提到同事 @李亮，在前期給了我很重要的幫助。
第 3 階段：<br />全職研究代碼，基本上一週發一篇文章。
這個階段雖然沒有收入，但是每天動力很足，有一種感覺就是日子過的紅紅火火。
這叫什麼？這就叫窮開心！
第 4 階段：<br />我上班了，只能利用業餘時間研究代碼。
想要像之前那樣寫長文章，還每週發一篇，已經不太可能實現了。
這個階段的主旋律就是圍繞問題研究代碼、寫文章，同事和讀者有時候會問我一些問題，我就圍繞問題去研究代碼，寫成文章。
開始一段時間，依然樂此不疲。雖然喫力，也還基本能應付過來。
時間一長，喫力感越來越明顯了，持續到 8 月份，寫文章之事就由於不堪重負暫時停了下來。
我還想繼續寫文章，但需要找到一種相對來說更輕鬆的方式，這樣才能可持續發展。
經過一番思考之後，我決定把寫文章的事放一放，先專心研究一段時間代碼，把 InnoDB 幾個主要模塊的細節都研究一遍，再接着寫文章。
時間飛快，轉眼已是四個月，從秋高氣爽到白雪皚皚，我恢復了元氣，又可以繼續寫文章了。
重生的文章，以系列的形式連載，需要新的載體，於是就有了這個專欄。
接下來，就要進入第 5 階段了。這個專欄和第 5 階段相伴而生，我在此許下一個願望：希望專欄和第 5 階段都能夠持續的很久~很久~，和大家一起奔赴未來！
5. 我們一起奔赴未來！
《MySQL 核心模塊揭祕》 專欄預期每週發佈一篇文章，持續一年左右。
接下來的一年，我們一起 探索 InnoDB 事務、鎖、Redo、Undo、MVCC 的底層原理，看看 MySQL 運行時都幹了什麼？
風起於青萍之末，浪成於微瀾之間。下一期（專欄的第 1 篇正式文章）我們會聊聊 InnoDB 事務的起源：事務池和事務池管理器。
更多技術文章，請訪問：https://opensource.actionsky.com/
關於 SQLE
SQLE 是一款全方位的 SQL 質量管理平臺，覆蓋開發至生產環境的 SQL 審覈和管理。支持主流的開源、商業、國產數據庫，爲開發和運維提供流程自動化能力，提升上線效率，提高數據質量。