訪阿裏資深專家丁奇：他是如何一步步成為MySQL大牛的？

丁奇認為，MySQL設計簡單，非常適合初創公司使用

丁奇（真實姓名：林曉斌），阿裏雲關係數據庫服務內核開發和運維團隊負責人，活躍的MySQL社區貢獻者。專注於數據存儲係統、MySQL源碼研究和改進、MySQL性能優化和功能改進。

近日，雲棲社區就MySQL之路、技術上的認識、團隊管理心得以及如何學習MySQL等話題，對這位MySQL領域大牛進行了專訪。

丁奇：本科學的是計算機應用，碩士階段師從葉東毅教授學習數據挖掘方向。之所以走上計算機這條路，是因為我本質上是一個懶惰的人，程序員是一個鼓勵“懶惰”和幫助“懶惰”的工作。

丁奇：為什麼會選擇做MySQL，這裏有個故事。剛開始我也是MySQL的小白，而且2008年的時候不像現在網上有那麼多前人經驗分享，當時MySQL的問題上網一搜，很少有現成答案。用的時候會碰到各種“詭異”的現象，又沒有資料可參考。比如平時一個更新語句執行響應時間都1毫秒，在線上偶爾會出現100毫秒。在貼吧這種對響應速度要求非常高的應用是能明顯感知的，這個是必須弄清楚去解決的。

主管問這是什麼原因，覺得是自己負責的模塊，臉皮薄不好意思說不知道，就說去查下，結果上網搜不到答案。

所幸MySQL是開源的，於是就自己去看源碼，也沒人可以請教，就硬看。結果居然把那個問題解清楚了。

然後就在內網分享了一下。結果同部門的其他組，像百度百科、百度知道那時候也開始大量用MySQL，他們又碰到了其他的一些問題，發現內網裏我寫的文章，以為對源碼很熟悉，也拿來一起討論。當時自己肯定是不懂的，但覺得他們提的問題也挺有趣，就又去翻代碼研究，然後把結果跟大家討論，把結論分享到內網，結果成了一個循環。

其實我自己工作中碰到的問題不多的，但是很多人的問題一匯聚，查多了慢慢覺得做數據庫底層還挺有意思的。

丁奇：在百度貼吧從事服務端開發的工作，當時負責的貼吧權限管理等，需要比較靈活的關係維護。剛開始是用我們自己設計的文件存儲來實現的，隨著需求變得靈活，我們當時決定用關係數據庫來維護。那時候選擇了MySQL，就此開始跟MySQL，算起來也有8年了。

丁奇：我當時在業務部門，研究數據庫源碼其實是工作時間外的事情，後來覺得如果有個工作可以專心做數據庫源碼也挺好的。剛好看到當時淘寶核心係統正在招MySQL源碼研發工程師，而且是章文嵩博士帶的團隊，就過來麵試看看。來之前的想法是即使麵不上，跟偶像見個麵說上話也是開心的。

過程還算比較順利。一個下午就把初麵到HR麵試走完了。章博士是技術終麵，他讓我介紹過去在MySQL上做的一些有意思的事情，然後他提出問題。當他第一個問題問出來以後，我差點懷疑章博士也做過數據庫內核開發。這其實對麵試官的要求很高，要很快的了解候選人陳述的最拿手事情的項目背景、解決方案，並能夠從中敏銳發現問題。

所幸我比較屬於會就說會，不會就說不會的類型，沒有被當場找到什麼破綻。相談還算甚歡，沒多久就入職了。

丁奇：現在來看，也算不了什麼成就。放在當時的技術環境還算不錯，今天就不值一曬了。比如說，給CDN業務做的TPS優化，從300提升到18000，在當時來看，這是一個比較複雜的存儲過程優化，但在今天來看就很正常。

另外，比較有意思的一事是：跟褚霸一起設計MySQL+Flashcache方案。那時候SSD剛在市場冒頭，大家還不敢拿來當存儲，就是作為二級緩存，拿開源的Flashcache來管理機械硬盤和SSD的配合。最開始的時候測試出來效果不行，其他團隊準備放棄這個方案。我跟霸爺就分頭啃代碼，我看innodb，霸爺看Flashcache。結果分析出來，原來Flashcache算刷髒頁閾值是按塊的，按照兩個源碼的設計初衷，默認的那種部署方式就是性能有問題。

有個場景記得特清楚：那時候還在創業大廈那邊，淩晨三點的時候改進部署，測試出來的效果跟我們分析代碼後的預估相同。那種開心真是無法言喻。在那幾天的分析中，也有些額外收益：從霸爺那邊偷師學了好多好用的工具。

丁奇：要說成就感，這些都有。但是要說“最”的話，還是多線程複製。原因可能顯得比較微妙，就像人家問100顆糖裏麵哪個最甜，大概是吃的第一個最甜。並行複製方案現在已經爛大街了，社區已經有4種以上的並行複製方案，但6年前這塊卻比較空白。

之所以能在6年前做出這樣的方案出來，主要還是因為阿裏這個平台。當時淘寶的業務發展非常迅速，需要做讀寫分離，但是有延遲的備庫無法提供業務查詢。我“潛伏”在各個業務群，發現幾個大業務都在討論這個問題。就自己分析原因，兩周寫了個版本，拿去DBA團隊推銷後，發現效果還不錯。當自己的方案保證沒有延遲的備庫提供業務讀，進而支持業務發展的時候，那一刻很有滿足感。

丁奇：這種要求7*24小時服務、管理數據的程序，修正錯誤的成本是非常高的。

對於這些困難，除了規範研發、代碼Reivew流程外，我們還增加了一些額外措施來解決，比如，對於Bug修複和通用功能，我們會將Patch提交到社區。這樣一來是回饋社區，二來可以收到一些反饋，最大的好處是如果官方吸收了Patch，我們就減少了維護工作量。

另外，我們也有一整套完善的自動化回歸測試、穩定性測試、係能測試、崩潰恢複測試和集成測試係統。主幹最新代碼更新後1小時內就會部署到這些係統中測試。

丁奇：這個問題有點大，我就說一個點吧，關於可診斷性。做數據庫運維的同學更多的強調的是可靠性、穩定性、性能等。

可診斷性包含但不隻是我們常說的監控。以MySQL為例，除了binlog記錄操作日誌外，是否有係統能力記錄所有的讀寫操作、是否有係統能力記錄至少半個月內的鏈路狀態隨時備查？以及每個語句精確到微秒的起止時間，執行過程中的資源消耗等。

擁有這些數據隻是基礎，重要的是要有對這些數據做實時分析的能力。一個簡單的問題是：作為一個DBA，如果你的業務方問你三個小時前，為什麼CPU 100%持續了5分鍾，你和你的係統有沒有能力在2分鍾內給出答案？

丁奇：最大的差別是我們已經接觸不到業務方。雲服務的本質是提供基礎服務，用戶拿到一個MySQL實例，就可以按照業務需求去使用。

而DBA的同學們都知道，DBA有一個重要的工作是做業務架構討論、業務評審、容量評估和SQL審核。因為這些都可能影響一個數據庫的運行狀態和服務質量。

但是在雲上麵，就沒有接觸業務方的機會。我們不再知道用戶什麼時候會上一個新業務，新業務裏麵包含多少全表掃描語句。這對我們的診斷係統、主動運維係統還有售後服務體係都是一個很大的挑戰。

丁奇：AliSQL分支上的特點是安全性和高性能。在安全上，我們有數據加密存儲方案。通過修改源碼，堵住了通過MySQL提權獲取本地文件係統權限的關鍵通道，在安全性上我們做了很多改進的工作。

高性能一直是AliSQL的標簽。從阿裏自身業務維護開始，積累的性能優化經驗都體現在AliSQL上，我們在執行計劃、io優化、壓縮優化上做了大量工作。

新增的功能也是AliSQL的一大亮點。我們有內置的支持秒殺場景的方案、有限製導出數據時單線程性能消耗的語法、高效清空線程占用資源減少內存消耗等功能。這些都是在長期服務內外部客戶時，從需求中抽象和實現的功能。

雲棲社區：你現在負責ApsaraDB for RDS、ApsaraDB for Postgresql 開發和運維；ApsaraDB for SQLServer 運維、基礎配置團隊，能否分享下你在團隊管理上的一些經驗？

丁奇：我自己是從一線工程師慢慢開始帶團隊的（好吧，其實現在也還是一線工程師），沒有專門學過管理，我遵循的原則主要是兩點：1.對他們好；2.換位思考。

我經常想自己剛工作的時候，希望得到主管什麼幫助，然後就知道該怎麼做了。

工作的安排是非常重要的。我給同學安排工作的時候的指標有以下幾個：

 

由於主管的信息和資源更多，對於應屆生或者工作時間較短的新人，上麵幾點我覺得並不難做到。

我的團隊裏麵還有好多像德歌、彭立勳、印風、玄慚這樣的高級專家，管理這樣的專家其實也是摸著石頭過河。

團隊跟人一樣，是有氣質的。在氣質改造上，團隊比人有優勢。一個人要改自己的氣質是很難的，而團隊的氣質是可以由很多人來互補的，由這些專家幫主管補上。

丁奇：先說優點吧。一個是方便上手，一個是現在網上資料多。很多問題，現在上網都能找到現成的答案和經驗，這就非常適合創業公司使用。畢竟大家還是看重業務，並且一開始也不會有很資深、很專業的DBA或者內核開發團隊的配置。

缺點就是跟其他的數據庫相比，能力還是比較簡單。MySQL設計之初的出發點就是為了簡單。雖然Oracle也在給MySQL發展各種能力，比如全文檢索、GIS等功能，但是相比於PostgreSQL，這些功能還是有差距的。

丁奇：MySQL有一個很好的引擎插件架構，這個就保持了增加各種能力的機會。官方5.7兼容json，5.6開始兼容NOSQL接口等等，就是為了把MySQL能力發揮出來。

後麵幾個大的數據庫方向基本上還是朝著超大容量、分布式、HTAP的方向走吧。

丁奇：首先數據庫的基本原理還是要了解，比如常見的存儲數據結構、內存淘汰算法等等。語言方麵MySQL是C/C++。

然後是最好有MySQL使用經驗。當然如果到我們團隊，即使沒有經驗，問題也不大，對於新人我們一開始就安排一些基本操作的練習，在線上值班過程中也會了解用戶的使用方法。

其實最重要的是學習能力，其他都好說。

丁奇：其實這個還是跟每個人的工作有關。如果是一個隻有語言基礎的新人，除了我上述說的了解基本原理以外，我覺得比較快的思路是參與一些比較簡單的功能開發。不論是社區還是所在團隊的需求。這樣你在完成過程中會對所涉及的這部分會有清晰了解。

之後就順藤摸瓜把相關的知識點弄清楚。基本上是一條線的感覺。

在有很多線的時候，就差不多是一個網了，這是一個很長的過程。到了網的密度很大的時候，就開始看MySQL手冊，這時候會把“網孔”補上。

我個人是不建議一開始就看MySQL手冊的，得有實戰經驗以後，去吸收才有效果，看了不會忘。

丁奇：可能每個人有自己的學習複雜係統的路徑，我自己是按照“帶著問題去調研”的心態去看的。

當你處於要從源碼中找出答案，來解心中疑惑時，一來有驅動力，二來是解決以後印象會很深刻，也有更多樂趣。

跟數據庫源碼打交道總體來說是一個很枯燥的過程，如果你試過不穩定複現多線程邏輯錯誤debug就知道。

丁奇：這裏引用正明離職時候，我在朋友圈發的內容：

“我的偶像、導師和引路人。有一種人是你遠看有光環，靠近更能感受他的魅力。淘寶核心係統是一麵旗幟，曆經種種變化，但旗幟一直在團隊裏流轉。很慶幸有那一段經曆，跟著章博士，做純粹的技術和技術人。”