丁奇：前阿里資深技術專家，極客時間《 MySQL 實戰 45 講》專欄作者。今天，他會分享自己是如何從小白成長為 MySQL 內核的開發人員的，跟大家談談經歷了哪些比較重要的事，哪些事最有成就感，哪些事比較有難度，以及是如何應對的。
我的經歷
以豐富的經歷進入百度
我是福州大學畢業的，據我了解，那時候我們學校的應屆生很難直接進百度，都要跳到浙大讀個研究生才行，後來我投簡歷居然進了面試。入職以後，我去問面試官為什麽讓我過簡歷篩選？他們說因為簡歷厚，因為我在讀書的時候，做了很多項目，實習過不少公司。當時印象很深刻的是，面試官問我，你有這麽多實習經歷，有沒有什麽比較好玩兒的事？然後我說，跟你說個數據量很大的事兒 ，在跟移動做日誌分析的時候數據量很大，有幾千萬行。他就笑了，後來我進了百度才知道，幾千萬行那都是小數據。
開始嘗試看源碼解決問題
當年進了百度，在貼吧做後端程式，比如權限系統等等。其實很簡單，就是寫一個 C 程式，響應客戶端請求，返回結果。那個時候我用的是 MySQL，但我只是個用戶。用了一段時間就出問題了，那個請求本來很快，但是偶爾又跑的很慢，老闆問是什麽原因，我又不好意思說不知道，就上網查資料，但那會兒是 08 年，網上資料很少，只好去看源碼，覺得源碼還蠻有意思的，而且真的可以解決一些問題，於是從那時候就進了坑。
混社區分享經驗
等到 2010 年的時候，阿里正好在招數據庫的開發人員，那時我還只是看得懂源碼，沒有什麽開發經驗，就說抱著試試看的態度去試一下，結果就成功進了阿里，跟著褚霸（霸爺）幹了 7 年多才離職。在百度的時候，基本上沒有在社區混，因為那時候百度可能更提倡內部分享，如何解決問題基本上都分享在內網裡。去了阿里以後，才建了部落格、開了微博，花名叫丁奇，部落格、微博、社區也都是用的這個名字。
丁奇《MySQL 實戰 45 講》，“碼”上訂閱
為什麽要了解數據庫原理？
下面我講幾個親自經歷的事情，聊聊為什麽要了解數據庫原理。
了解原理能幫你更好地定位問題
有一次寒假同學聚會，大家談起技術問題。一個在政府裡的同學說他們的系統很奇怪，每天早上都得重啟一下應用程式，否則提示連接數據庫失敗，他們部門的人都不知道該怎麽辦。我分析說，按照這個錯誤提示，應該就是連接時間過長了，斷開了鏈接。數據庫默認的超時時間是 8 小時，政企六點下班，下班之後系統就沒有人用了，等到第二天早上九點甚至十點才上班，都超過 10 個小時了，肯定就會斷開鏈接。估計那個系統程式寫得比較差，連接失敗也不重連，仍然用原來斷掉的連接，就會報錯。於是讓他回去把超時時間改長一點，結果這個問題就解決了。我們作為開發人員，即使只知道每個參數的意思，可能就可以針對一些問題給出正確的應對方法。
了解原理能讓你更巧妙地解決問題
我在做貼吧系統的時候，每次訪問頁面都要請求一次權限。所以，這個請求權限的請求，訪問概率非常高，不可能每次都去數據柯瑞查，怎麽辦？我想了個簡單的方案，在應用程式裡面開個很大的記憶體，啟動的時候把整張表全部 load 到記憶體裡去，這樣請求過來，直接從記憶體裡取就行了。數據庫重啟時，我的進程也會跟著重啟，接下來就會到數據表裡面全表掃描，把整個用戶相關資訊全部塞到記憶體裡面去。但是，後來遇到一個很鬱悶的情況。有時候 MySQL Crash 了，我的程式重新加載權限到記憶體裡，結果這個 select 語句要執行 30 分鐘左右。本來 MySQL 正常重啟一下是很快的，進程重啟也很快，正常加載權限的過程只需要兩分鐘就跑完了，為什麽異常重啟的時候就要 30 分鐘呢？後來我沒轍了，只好看源碼，發現 MySQL 有個機制，當它覺得系統很空閑時會盡量去刷髒頁。具體到我們的例子裡，MySQL 重啟以後，會執行我的進程做全表掃描，但是因為這個時候權限數據還沒有初始化完成，我的 Server 層不可能提供服務，於是 MySQL 裡面就只有我那一個 select 全表掃描的請求，MySQL 就認為現在很閑，拚命的刷髒頁，吃掉了大量的磁盤資源，導致我的全表掃描也跑得很慢。知道了這個原理，我就寫了個腳本，每隔 0.5 秒發一個請求，執行一個很簡單的 SQL 查詢，告訴數據庫其實我現在很忙，髒頁刷慢點。腳本一發布使用，果然髒頁刷得慢了，加載權限的掃描就跑得很快了，據說我離職兩年多以後，這個腳本還在用。你看，如果我們懂得一些參數，可以理解這些參數，就可以做正確的設定，進一步懂得一些原理，就可以更巧妙地解決問題。
看得懂源碼讓你有更多的方法
2012 年的時候，阿里雙十一業務壓力比較大，那個時候是機械硬碟時代，不像現在，SSD 很多。為了應對壓力我們開始引入 SSD，但是不敢把 SSD 直接當存儲用，而是當二級緩存。當時用了一個叫 Flashcache 的開源系統，不知道大家有沒有聽過，現在已經是老古董了。Flashcache 實現把 SSD 當作物理盤的二級緩存，可以提升性能。但是我們自己部署後發現性能效果沒有預想的那麽好，甚至還不如純機械盤。我跟霸爺就開始研究，霸爺負責分析 Flashcache 的源碼，我負責分析 MySQL 源碼。後來我們發現 Flashcache 是有髒頁比例的，當髒頁比例到了 80% 就會停下來強行去刷盤。一開始我們以為是全部的 20%，後來也是看了源碼才知道，原來它分了很多個桶，比如說一個桶 20M，這個桶如果用完 80%，它就認為髒頁滿了，就開始刷。這就意味著如果你是順序寫，很容易就把一個桶寫滿。知道這個原理後，我就把日誌之類順序寫的數據都放到機械硬碟，隨機寫的數據放到 Flashcache 上，效果就好了。大家看，如果你看得懂一些源碼，你的操作行為就會不一樣。
MySQL 學習路徑
其實我剛剛講的就是學習路徑。首先是要會用，要去了解每個參數的意義，這樣你的運維行為（使用行為）就會不一樣。千萬不要從網上拿了一些使用建議來，別人怎麽用，你就怎麽用，而不去想為什麽。再往後，就要去了解每個參數的實現原理是什麽樣的。一旦你了解了這些原理，可能你的操作行為就會不一樣。 再進一步，如果你看懂源碼，你對數據庫的理解也會不一樣。
再來講講我是怎麽帶應屆生的，實踐是種很好的學習方式，我會讓新人來了以後先搭主備，然後你會發現每個同學的自學能力都不一樣。比如遇到有延遲，或者我們故意構造一個主備數據不一致的場景，讓新人了解怎麽分析問題，解決問題。
那從學習路徑來說，首先就要會用，然後可以發現問題。在我的《MySQL 實戰 45 講》裡，會出一些常見的問題，這些問題都不會很難，跟課程掛鉤，但又無法直接從文章裡拿到答案。大家可以嘗試先不看答案自己思考，或者去數據庫翻一翻，會是一個不錯的過程。下一步就是實踐，之後當你覺得開始有一些“線”的概念了，再去看MySQL 的官方手冊。在我的專欄裡，有人問要不要直接去看手冊？一開始千萬不要看，裡面有 100 多萬個英文單詞，你就算再厲害，也是看了前面忘了後面。所以一定要自己先有脈絡，然後有一個知識網絡，再看手冊去查漏補缺。我自己就是這麽一路走過來的。
DBA 的修煉
DBA 和開發有什麽相同點？
正好我帶過開發團隊，也帶過 DBA 團隊。其實 DBA 本身要有些開發底子，比如說做運維系統的開發。另外，自動化程度越高，DBA 的日常運維工作量就越少，DBA 得去了解開發業務邏輯，往業務架構師這個方向去做。開發也是一樣，不能所有的問題都指望 DBA，DBA 在每個公司都是很少的幾個人，開發也需要對數據庫原理有一定的了解，這樣向 DBA 請教問題時才能更專業。所以兩個崗位應該有一定程度的融合，開發要了解原理，DBA 要了解業務和開發。
運維 DBA 有前途嗎
每個崗位都有前途，只是要根據時代不同稍微調整一下方向。像原來開玩笑說 DBA 要體力好，因為得搬伺服器。後來核心技能成了會搭庫，會主備切換，但是現在這些也不夠用了，因為已經有了自動化系統。接下來一方面是要了解業務，做業務的架構師；另一方面，是要有前瞻性，做主動診斷系統，把每個業務的問題挑出來，做成月報，讓他們優化，你幫他們優化好了，可以把優化的指標呈現出來，體現出你對公司的價值。
有哪些比較好的習慣和提高 SQL 效率的方法
要多寫 SQL，培養自己對 SQL 語句執行效率的感覺。以後再寫或者建索引的時候，知道這個語句執行下去大概的時間複雜度，是全表掃描還是索引掃描，是不是需要回表，在心裡都有一個大概的概念，這樣寫出來 SQL 會快一點，而且不容易犯低級的錯誤。這也是我們《MySQL 實戰 45 講》專欄的目標。
看源碼需要什麽技術
一是要掌握語言，C 跟 C++。另外還要熟悉一些調試工具，代碼是靜態的，運行起來是動態的，看代碼是單線程的，運行起來是多線程的，所以要會調試。還有，不建議用可視化的工具，它雖然很方便，但你不知道這個操作點下去實際本質上做了什麽，所以建議自己手寫代碼和 SQL 語句，讓自己更明白一些原理。
怎麽學習 C、C++？
我在讀研的時候 C 和 C++ 的學習進步最大。那時，去給專科上 C 和 C++，覺得已經會了，完全教得了。但去的時候才知道，自己會跟能夠教別人是不一樣。備課的時候，發現不能隻講會用的部分，還得把原理講清楚。這樣就倒逼著自己進行更深入更全面的學習。有的人看完技術部落格和專欄，會把這篇文章的提綱列一下，寫寫自己的問題和對此的理解，這個過程很有利於學習。因為你聽進來是一回事，講出去是另一回事。
學數據庫要什麽心態
不只是數據庫，所有多線程的服務，過程都是很枯燥的，遇到問題會很麻煩。但是，最後你找出問題時的那一下會很爽，我覺得你得找到這種感覺，它可以支持你接下來又枯燥很久，這樣才能深入地堅持下去。
現在訂閱，限時優惠?68，原價?99，12 月 18 日恢復原價。
香港九龍灣馬來街興發大廈15樓D室