師從前阿里技術專家丁奇，我是如何提升MySQL的？

出處：極客時間《MySQL 實戰 45 講》

對於做後端的同學，MySQL 是繞不過的一道「坎」。前阿里資深技術專家丁奇在極客時間開了《MySQL 實戰 45 講》專欄，內容覆蓋從原理到實戰，非常受歡迎。今天，給你分享幾個專欄用戶故事，希望他們的學習經驗和方法，對你的 MySQL 學習之路有所幫助。

我是一名有著十多年開發經驗的程序員，喜歡技術，熱愛編程，現在北京特微智能科技有限公司工作，擔任北京軟體研發部經理。

本人工作中使用 MySQL 快 10 年了，OLTP 與 OLAP 都做過，看過很多 MySQL 的書，自我感覺對 MySQL 還算熟悉，所以最初看到《MySQL 實戰 45 講》的目錄時，並沒有太多感覺，就是些常見問題嘛。但是，出於對極客時間課程質量的信任，我還是買了，就當是查缺補漏。

但是，文章更新出來後，可不得了，雖然目錄沒什麼出奇之處，但內容的組織方式卻完全不同於其他書籍和課程：以實際問題驅動，講解深入淺出、生動有趣，幫我重新梳理了 MySQL 的知識體系，進而使得我在實際使用 MySQL 的過程中更加得心應手。

因為自己的知識體系更加完整了，所以在生產環境中出現問題的時候，我可以更加冷靜的去思考，直奔問題本質，不再是各種盲目試錯。這，也算是我學習這個專欄的最大收穫吧。就比如說：

第 24 講 | MySQL 是怎麼保證主備一致的？

第 25 講 | MySQL 是怎麼保證高可用的？

第 26 講 | 備庫為什麼會延遲好幾個小時？

第 27 講 | 主庫出問題了，從庫怎麼辦？

第 28 講 | 讀寫分離有哪些坑？

第 29 講 | 如何判斷一個資料庫是不是出問題了？

不僅解釋了我們之前出現備庫延遲的原因，也讓我對我們後續要採用的資料庫高可用架構更有信心，對我的幫助非常大。

總的來說，這門課程是有深度的，初級工程師第一遍應該會看不太懂，但是一旦看懂了，對 MySQL 的理解就會有質的飛越。以我的經驗來看，搞懂這 45 篇文章的知識點，你的 MySQL 水平會超過 80% 的高級工程師。所以，我也希望處於技能徘徊階段的上進青年能早些學習這門課程，對自己、對團隊、對公司來說都有莫大的好處。

最後，還得稱讚一下極客時間課程的質量。以前在別的平台上聽過很多課程，突出的問題就是老師講課廢話多、口語不斷，各種無用的「嗯」「啊」，各種沒有意義的重複，這不是學習，而是遭罪，往往聽著聽著就走神了，再回過神時，關鍵知識點已經講完了。而極客時間上的課程，講述流利、內容也都是經過認真打磨的，聽課時給我的感覺就是非常過癮，現在在上下班路上、在堵車時，再也不會感到焦躁不安了。

小編提示：《MySQL 實戰 45 講》限時 24 小時拼團￥79，原價￥99，已有超過 2.8w 人加入學習，想認真進階 MySQL 的同學，請抓緊搭上這趟快車（方式：掃上圖二維碼）

我是一名即將畢業的碩士，專業是電路與系統，方向是信息對抗，實驗室主要的工作內容是雷達系統設計和電子戰相關的演算法研究。校招的時候，因為我對信息對抗領域的興趣不大，因此找了 Java 開發工程師的工作。

在這個跨專業的過程中，我開始自學計算機專業的基礎知識，數據結構與演算法以及計算機網路的部分學習其實並沒有難度，但是資料庫就不太不一樣了。我看了不少資料庫的資料，腦海中充斥的都是零散的理論和大量的命令，但是對資料庫的認識卻一直停留在簡單應用的層面，而對於底層是如何支持以及實現這些命令等問題卻並不清楚。

也就是說，我面臨的問題是，雖然攝入了大量知識，但是無法利用這些知識構建起穩固的大廈。而我也明白，我缺少的是實戰的磨練與系統的知識結構。

《MySQL 實戰 45 講》專欄，解決了我的很多疑問。以「第 04 講 | 深入淺出索引（上）」和「第 05 講 | 深入淺出索引（下）」為例，林曉斌（丁奇）老師從索引的常見模型出發，介紹了常見的資料庫引擎可用的 3 種數據結構，從使用的角度介紹了三種數據結構的優缺點，並通過實例分析了三種數據結構選擇的原則，以及索引模型在資料庫問題分析中的重要作用。這個分析，讓我意識到了索引模型或者說底層數據結構對於資料庫的意義。

接著，老師以 InnoDB 為例分析了它的 B 樹結構以及選擇 B 樹的原因，並且引出了主鍵索引和普通索引的區別與選擇原則，讓我對這些常見的索引以及索引的選擇有了一定的認識。

在這個實例的基礎上又分析了索引在資料庫引擎中是如何維護的，從性能和存儲空間的角度分析了自增主鍵和業務邏輯欄位做主鍵的應用場景。這個分析讓我認識到了資料庫索引的選擇其實還是取決於業務場景與底層邏輯的匹配性。

接下來，深入地討論了資料庫索引相關的概念，包括覆蓋索引、前綴索引、索引下推這些概念，分析了不同的索引出現的價值和意義。通過具體的實例分析了不同的查詢語句背後所使用的索引，從索引的搜索次數（即性能）以及空間 2 個方面分析對比了不同的業務場景選擇索引的原則。總結一下，在滿足語句需求的情形下，盡量少地訪問資源是資料庫設計的重要原則之一。

其實，從這 2 篇文章中，我學習到的不止是書本中的資料庫相關的知識，更重要的是建立起了資料庫學習中「理論 - 實現 - 應用 - 問題 - 解決 - 精進」的學習閉環，幫助我一步步地建立起自己的知識結構。這個非常重要，因為完整的知識結構能夠賦予我舉一反三和解決問題的能力，而不再是簡單的 CRUD。

所以，我覺得這個專欄，也特別適合我這種已經接觸了大量的資料庫資料，但還沒建立起自己的知識網路的同學們。

我是一個普通的九零後技術男，從事後端開發工作五年多了，現在是一名小主管。

2018 年的時候，我正處於瓶頸期。我深知自己的短板就是基礎知識不夠紮實，有焦慮，也有求知慾。就在這時，極客時間走入了我的世界。我目前已經訂閱了 14 個專欄，有的已經學完了，有的正在學。

腳踏實地地學習，讓我不再那麼焦慮、彷徨。而在系統性地學習專欄的過程中，我確實在架構設計、網路協議、數據結構、資料庫等方面有了更深入的理解，也逐漸度過了瓶頸期。

說到我學習《MySQL 實戰 45 講》專欄的最大收穫，就是對資料庫的底層執行過程更了解了，然後我就能夠從另一個維度去觀察它了。

比如以前，我不知道一條 SQL 語句在資料庫中是如何運行的。而現在，我經常會腦補一條 SQL 語句在連接器、查詢緩存、分析器、優化器、執行器、存儲引擎的執行流程，如下圖。

再比如，「第 16 講 | 「order by」是怎麼工作的？」，講的是關於 order by 的內容。

大家都知道 order by 是用來排序的，但它是如何執行的？用到了什麼排序演算法？如何優化大數據量排序很慢的問題？

學到這節課後，以上問題我都回答出來了。我在學完這篇文章以後，也整理了自己的思維導圖，這個整理過程又加深了我的理解。

還有一個讓我感觸特別深的案例，有一次我在工作上遇到了一條複雜的 SQL 語句執行很慢的問題，200 萬的數據量居然要執行好幾分鐘。之後，我用 sql server profiler 查看執行計劃，原來是進行了全表掃描。

這些數據的特點是，查詢多、修改少。所以，我在給 where 條件的一個欄位加了索引後，執行計劃從全表掃描變成了索引掃描，掃描行數降低到 50w，速度快了一個量級。

順便說一下，添加索引有利有弊，要綜合考慮。學完「第 11 講 | 怎麼給字元串欄位加索引？」後，你就知道如何用好索引了。

這裡，我也順便和你分享幾個我在學習中用到的軟體：

Forest（一款番茄工作法的軟體，25 分鐘一個周期），用來專註學習。

XMind（一款思維導圖軟體），用來做筆記，方便複習。

Anki（一個記憶神器），用來記憶，製作 Anki 卡片後，可以通過問題、想答案、對答案。

最後，學習沒有捷徑，只能一步一個腳印、死磕一個又一個的知識點。就像陳皓老師在《左耳聽風》中說的：

有很多知識我把其稱作為「硬核知識」，這類的知識就像硬核桃一樣，相當難啃。就像那些數學公式、計算機底層原理、複雜的網路協議和操作系統的調度等等，這些知識，你除了死磕之外，沒有其它的辦法。

小編提示：《MySQL 實戰 45 講》限時 24 小時拼團￥79，原價￥99，已有超過 2.8w 人加入學習，想認真進階 MySQL 的同學，請抓緊搭上這趟快車（方式：掃上圖二維碼）

我是一名來自深圳某互聯網金融公司的後台開發小哥，每天都會跟資料庫打交道。在遇到《MySQL 實戰 45 講》之前，雖說寫了三年的業務代碼，但對 MySQL 無太多深層次的認識，只停留在 CRUD 層次，能滿足業務邏輯就萬事大吉。我甚至不知道索引為什麼能提高查詢效率。

對 MySQL 知識的匱乏，導致我平時總是迴避與同事討論 MySQL 相關的問題。現在回想，以前自己也犯過很多錯：

1. 主鍵使用 UUID，非自增主鍵；

2. 聯合索引內的欄位順序隨意排放；

3. 濫用索引，創建盡量多的索引來提升查詢效率；

4. 不管 SQL 語句是否合理，只要能返回結果集就是好 SQL。

學習專欄後，現在每天看到資料庫和 SQL 語句，我想的最多就是鎖、索引和事務。

現在我在設計表結構時，會根據業務反覆推敲每個索引的合理性。這時，我的大腦里總是會浮現出一棵棵的索引樹，在所有索引樹上將業務邏輯走一遍。就像小說里的武林高手看到對手的招勢時，早已在大腦里演練完了所有招勢，保證一招制敵。

我也經常在辦公室聽同事們討論聯合索引的最左前綴原則：通過 name 欄位查詢，可以走這個聯合索引，因為 name 欄位是聯合索引的最左欄位。如果遇上更熱心的同事，會在紙上給你羅列出所有索引的情況，如聯合索引 (A, B, C)，包含了下面這些索引：(A)、(A,B)、(A,C)、(A,B,C)。

看他說得頭頭是道，感覺真是這麼一回事，然後我自己也就記下了排列組合的公式。下次再遇上這種情況，照貓畫虎，不管結論是否正確，肯定可以唬住對方。

學習專欄後，我才發現上述解釋是不正確的。當你知道了聯合索引是一棵 B 樹，葉子內容按照欄位順序排列以後，就已經掌握了最左前綴原則：最左前綴除了可以是聯合索引的最左 N 個欄位，也可以是字元串索引的最左 M 個字元。

除了上述最左前綴原則的認識有所偏差外，對模糊查詢是否走索引，也存在不恰當的認識：模糊查詢不走索引，所以查詢速度特別慢。針對這種情況，我來舉個例子說明一下索引使用問題：

select*from user where name like"j"或"j%"或"%j"或"%j%";

大部分同學會認為前面 2 種情況（"j"或"j%"）可以使用索引，而最後 2 種情況（"%j"或"%j%"）不能使用索引。理由很簡單也很有力：索引是用來提高查詢的效率的，如果後面 2 種情況使用了索引，那為啥它們的查詢速度這麼慢。

這種解釋看起來挺有道理的，但說法是不正確的，原因在於沒弄明白「用索引」和「用索引快速定位記錄」的區別：

1. like "j" 或 "j%" 可以使用索引，並且快速定位記錄，表象就是查詢速度很快。

2. like "%j" 或 "%j%"，只是在二級索引樹上遍歷查找記錄，並不能快速定位（使用了索引，但是掃描了整棵索引樹），表象就是查詢速度沒那麼快。

如果說某一篇文章讓我覺得特別有用的話，我推薦「第 18 講 | 為什麼這些 SQL 語句邏輯相同，性能卻差異巨大？」

文章分享了慢 SQL 中比較經典的三個案例，並對每種情況進行全面講解和分析。當再遇到慢查詢的問題時，我回憶起文章的知識，這些問題就能迎刃而解了。在平時開發中，我養成了通過 explain 來「腦補」一條 SQL 語句執行流程的好習慣，防止掉入隱式類型轉換的陷阱，而帶來不堪設想的生產事故。

通過學習專欄，我糾正了自己很多不正確的認識。現在我也會反覆學習專欄中的每一篇文章，每次學習都有不一樣的收穫。

第一次：了解文章的各種概念，記錄不理解的地方和疑問點，記錄自己的對知識點的理解。

第二次：形成一個比較清晰的邏輯，對它的實現原理有了更深的認識，這次基本解決第一次學習時遺留的問題。

第三次：MySQL 的這種實現原理，是為了解決什麼問題，帶來的負作用。而未來自己做設計時，能否借鑒這種實現方式。

我也很喜歡丁奇老師的寫作風格，老師會在文章開頭拋出問題，接著開始講解相關概念和剖析原理，然後引出工作中的應用場景，分析各種方案的利弊，最後總結和答疑。每次總被文章深深吸引，學習後讓人回味無窮，意猶未盡。

除了丁奇老師的文章寫得流暢清晰、通俗易懂之外，還有另外一個要大力推薦的是評論區。評論區卧虎藏龍，總能在評論區學習到文章以外的知識。每個評論老師都會認真閱讀和回復，使得評論區特別活躍。

我非常感恩，跟著老師學習，讓我體會到了學習是一件自然而又充滿魅力的事情，也讓我從一個基礎不牢固的小白，一步步地充實了自己的知識庫。另外，老師非常盡責，經常半夜回復和答疑，希望老師保重身體。謝謝！！

1 天拼團福利

在《MySQL 實戰 45 講》中，丁奇會幫你梳理出學習 MySQL 的主線知識，比如事務、索引、鎖等，還會就開發過程中經常遇到的具體問題和你分析討論，並且幫你理解問題背後的本質。你會收穫 MySQL 核心技術詳解與原理說明和 36 個 MySQL 常見痛點問題解析。

最後，小編再提示下，《MySQL 實戰 45 講》限時拼團￥79，原價￥99，已有超過 2.8w 人加入學習，想認真進階 MySQL 的同學，請抓緊搭上這趟快車（方式：掃下圖二維碼）

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！