MySQL DBA的修煉與未來，看看老司機們怎麼說？
隨著MySQL地位爆炸式的提升， MySQL DBA的市場缺口日益劇增，優秀的MySQL DBA正在成為各個網際網路公司搶手的人才。然而，需求來了，問題也來了，如何快人一步提高自身技能，讓自己在日益激烈的技術挑戰中不斷增值、脫穎而出？
今天，我們將鎖定MySQL資料庫，通過韓鋒、虢國飛、楊奇龍、楊建榮、張青林、李輝、賀春暘、李季鵬等8位MySQL專家的經驗之談，為想從事MySQL DBA的同學們答疑解惑，指明一條修煉的路子。
目錄大綱
認真讀完本文，你可以瞭解到：
一、選擇篇
1、MySQL的流行原因及從業前景
2、MySQL DBA的薪資緣何普遍高於Oracle DBA
3、個人如何完成Oracle向MySQL的轉型？
二、學習篇
1、從初級到高階的MySQL DBA學習路線及學習資料推薦
2、原始碼是否為高階MySQL DBA的必備技能？
3、MySQL不同分支的選擇討論
4、MySQL認證考試的含金量
三、趨勢篇
1、隨著功能的不斷完善，MySQL還會是“小而美”的代表嗎？
2、MySQL目前還缺乏哪方面的能力，是否足夠成熟？
3、如何看待資料庫中間層與資料庫的關係？
4、傳統運維逐步萎縮下，DBA應選擇什麼方向發展？
四、未來篇
1、資料庫雲化會對傳統DBA帶來什麼樣的衝擊？
2、如何看待分散式資料庫的未來前景？
3、越來越多的DBA正在或將從事DevOps類工作，你的看法是？
選擇篇
Q1：你認為MySQL流行的主要原因是什麼？從長遠角度來看，從業前景如何？
1、流行原因
虢國飛：綜合來看，MySQL的流行是偶然中的必然。原因主要有以下三點：
- 免費：傳統資料庫昂貴的license費用是很多企業一塊心病，MySQL社群版已經能滿足大部分使用者的需求，而且是免費的，自然在企業內部推廣時不會遇到阻力（老闆們肯定支援）；
- 開源：開源的好處是隻要你想，你可以深入到程式碼級別來了解資料庫的運作原理（甚至可以改造它），這個遠勝於傳統黑盒資料庫只是簡單輸出一些log或者白皮書來讓人猜測運作情況，開源能讓DBA能知其然並知其所以然，而且開源社群還有豐富的工具，給DBA在維護上面提供了強大的支援。 DBA能在社群快速找到自己需求的東西，組合成自己的工具箱，所以社群工具的豐富也彌補了產品本身的缺陷；
- 簡便：這一點使得MySQL部署簡單，新手學習門檻低、上手快（當然要真正掌握好還是需要大量學習的），不要花費太大的精力就能快速搭建起一套高可用的叢集來，而不像Oracle資料庫那樣，有很多配套東西需要了解，沒有幾年的學習很難掌握，對於新手來講都會覺得挺難的，所以MySQL能在DBA群體（甚至包括開發人員）中快速地普及。
2、就業前景
李輝：目前來看，MySQL DBA的日子還是很滋潤的，在可預見的3-5年內，MySQL在網際網路行業的地位仍無法取代，對DBA的需求量仍然很大，特別是中高階DBA。但從長遠角度來看，從業人員也要多涉獵其它關係型資料庫以及NoSQL、Devops、雲端計算等技術，現代社會唯一不變的就是變化，不斷學習、擁抱變化才能保證自己不被未來社會淘汰。
Q2：如何看待當前MySQL DBA的薪資普遍高於Oracle DBA的現象？如果想從事DBA，選哪個資料庫更好？
1、MySQL DBA高工資的原因
楊建榮：因為是和Oracle來對比，可以分為幾個方面來看：
- 首先物以稀為貴，MySQL DBA相對Oracle DBA來說要少一些，隨著現在網際網路行業的發展，這個需求還是會持續增長；
- 第二還是物以稀為貴，任何工種，高階職位都是稀缺的，如果你能夠成為行業內的20%的人，無論你是從事哪種資料庫，都會混得還不錯。
- 第三還是物以稀為貴，什麼事物的發展都有一個成熟度曲線，水漲船高之後，留在你手裡的是真技能還是花拳繡腿，資料庫的功能會越來越豐富，你的技能也要升級，不升級的話，用哪個資料庫你都會很吃力。
楊奇龍：對於薪資高這點，我覺得要從兩方面看：
- MySQL DBA和Oracle DBA 的僱主行業不一樣，MySQL DBA 多屬於網際網路等新興企業，大多數是資本聚集，而Oracle DBA 則從事於傳統或者部分大型企事業單位。兩種企業的薪資平均水平本就有差距。
- 從技能要求上，MySQL在功能上比Oracle “弱”或者說不完善，需要DBA具有更高的技術掌控能力做HA、備份、恢復、校驗等。Oracle 則提供了比較完備的功能。
2、從事DBA崗位，選MySQL還是Oracle？
楊建榮：有句話說，選擇的利劍屬於在於能夠揮舞它的人，根據工作需要，自己的喜好去選擇就可以，如果只是本著錢途是不推薦的。如果非要糾結到底是哪一個，其實也可以換個角度，如果兩個都學，是不是這個問題就不是問題了。
楊奇龍：我的想法比較實際。行行出狀元，不管是MySQL DBA 還是Oracle DBA都有比較成功的人士，建議是看各自的興趣和愛好，以及自己想進的公司的招聘需求。MySQL 和Oracle 並不矛盾，我認識的相當多的人，兩種資料庫都能維護得非常好，比如大牛樓方鑫，Oracle 工具開發以及MySQL 核心開發都有非常出色的成果。
Q3：個人職業發展如何完成Oracle向MySQL的轉型？
楊建榮：從自身目前從事的工作，分三種情況來看：
（1）目前從事的工作以商業資料庫Oracle為主，又想轉型為MySQL DBA的：
自搭環境學習實踐是一個起步，如果覺得沒有明確的學習目標，考個MySQL OCP也是一種階段性的學習成果驗收，總比漫無目的的學習收穫要大。已經有了Oracle基礎，可以通過對比的方式來引入到MySQL的學習中。公司如果後期引入MySQL方案，你就是最佳人選了。
（2）目前工作中有MySQL環境的：
在做好本職工作的前提下，可以自薦，讓別人推薦來做MySQL DBA的工作。對企業和你個人都是雙贏，所以開發測試運維同學相做MySQL DBA也是可以的。
（3）現有的MySQL工作和自身期望相比差距較大的：
一種方式是自查，我們在當前的環境還能夠做出些什麼，如果能夠把當前的環境做到精細化的管理，總會有非常多的事情和收穫，還有一種方式就是跳槽，這個的前提也是你在儲備了很多的技能之後，因為機會是留給有準備的人。
虢國飛：我是從SQLServer轉型到MySQL的，感覺這個轉型應該比Oracle轉MySQL更大，因為本身還要克服作業系統的區別（Windows轉型Linux），不過如果你已經有一個數據庫產品的經驗，再來學習其它資料庫產品，難度應該不是很大，因為很多底層的原理是相通的，概念也差不多，無非是各種產品在設計上側重點有不同、使用方式上有差異。
所以我覺得要完成這個學習轉型，首先心態上面應該放開（千萬不要帶偏見，認定哪種好哪種不好），通過對比的方式來學習和實踐，善於總結差異分析優劣，多和同行溝通交流，相信轉型過程不會太長。
李季鵬：從Oracle到MySQL轉型，不單單是一個人的學習過程，也是一個從開發到運維的磨合過程。
- 首先，戰略上要藐視敵人，熟練掌握Oracle的話，對於任何一種關係型資料庫的學習都是事半功倍的，特別針對MySQL，可以視為一個功能和手段做減法並尋找替代手段的過程；
- 但重要的是，戰術上要重視敵人，限於MySQL的特點，特別是中大型場景，把MySQL當Oracle用只會更加痛苦，必須放棄原有的Oracle視角，堅持MySQL大而化之的特點。
學習篇
Q1：從初級成長到高階，有推薦的MySQL學習路線嗎？
楊奇龍：DBA 是一個“複雜”的工種，要成為高階/資深MySQL DBA，我總結了以下五點：
- 官方文件是最好的學習資料。通讀官方文件是最紮實的學習方式，目前大多數同行只是把官方文件當做參考資料。其實把官方文件理解透徹你已經能成為高階DBA了。
- 紙上來得終覺淺，絕此事要躬行。多動手，多做實驗驗證技術功能點。
- 找一個有業務量的平臺，鍛鍊自己的技術能力。
- 能幹活，能寫文件，能講。能夠將自己理解的知識教會其他人才算真的弄懂。
- 不懂業務的DBA 不是優秀的DBA，能夠思考如何儲存資料，也要會和開發溝通討論業務如何訪問資料才算最合理的。
參考DBA技能樹
http://blog.itpub.net/22664653/viewspace-2097142/
楊建榮：DBA乾的是一個手藝活（鷹眼，獅心，女人手），裡面有很多技巧，但是一個崗位從初級走向高階始終是經驗和實踐的積累，沒有其它捷徑。這裡給大家提供一個自查級別的方法：
Q2：關於MySQL學習資料、書籍或網站，你的推薦是？
楊建榮：簡單來說，官方文件是最好的學習資料，在這個基礎上去閱讀更多的書籍會起到融會貫通的作用。如果推薦書籍，我有下面的一個讀書清單可供參考。
入門：
《塗抹MySQL：跟著三思一步一步學MySQL》
《MySQL資料庫應用從入門到精通（第2版）》
《MySQL核心技術手冊》
《MySQL技術內幕（第5版）》
運維實踐：
《高效能MySQL》 經典必讀
《MySQL管理之道：效能調優、高可用與監控（第2版） 》賀春暘
《深入理解MySQL核心技術》帕奇維
《MySQL運維內參》 周彥偉、王竹峰、強昌金
《高可用MySQL》
核心：
《MySQL技術內幕：InnoDB儲存引擎（第2版）》姜承堯
《InnoDB – A journey to the core》Jeremy Cole
楊奇龍：在建榮老師的基礎，我再推薦：系統優化-《效能之巔》、開發-《Python 程式設計:從入門到實踐》
張青林：《資料庫系統原理》、《InnoDB儲存引擎》。
李季鵬：最為建議的還是官方文件，如果嫌官方文件英文看著麻煩，可以關注Github上的MySQL 5.6 手冊翻譯專案(mysql2cn/manual56)。
Q3：你認為研讀原始碼是通向高階MySQL DBA的必備技能嗎？
楊奇龍：從我的理解來看 DBA 可以分為產品DBA、運維DBA、核心研發DBA。具有核心研發能力或者閱讀核心原始碼的人，在瞭解具體技術原理時具有一定的優勢。但是成為高階DBA和是否研讀原始碼不衝突。
需要注意的是，我們要有打破砂鍋問到底的“要性”。其實大牛和我們的差距就是對於一個個技術問題刨根問底的及時鑽研。比如你遇到thread running飆高的問題時，是把慢查詢優化了就好了嗎？還是舉一反三，反思什麼原因會導致thread running飆高？要懂得去思考下面四個問題：
- 業務是否需要快取或者非同步更新？
- 連線池配置是否合理？
- 是否當時系統磁碟io有問題亦或是raid 卡充放電怎麼避免生產時刻重放電？
- thread running 代表什麼意思？如何配置才能達到最好效果？
能否成為高階DBA，在於我們是否解決了一般人解決不了的問題的能力。
張青林：首先，我不認為讀原始碼是通向高階MySQL DBA的必備技能，即使不讀原始碼，也是可以成為高階MySQL DBA的。讀原始碼是為了瞭解其工作原理，分析其瓶頸，然後從核心上做優化，這是核心研發的必備技能；做為運維人員，只要懂其原理、使用方法，處理線上問題，並配合研發人員對線上進行維護，一樣是很高質量的工作，也是“原始碼”落地的最重要的一部分，所以不可厚此薄彼。 當然，讀原始碼可以更深層次的理解核心的工作機制，有利於學習。
Q4：針對MySQL的不同分支(Oracle官版、Percona、MariaDB)，你更看好誰？
韓鋒：我還是看好Oracle官版。過去幾年，官版MySQL的發展有些滯後，導致很多人選擇了其它版本，Oracle也看到了這一點。最近一兩年，隨著MySQL5.6、5.7乃至8.0的推出，官版已經逐漸追上了其它分支版本。依託於Oracle在資料庫領域的深厚底蘊，未來官版MySQL的發展更加看好。
如果選擇的話，我推薦的順序是：MySQL社群版->Percona->MariaDB->MySQL企業版。
張青林：我更看好 Oracle 官方版本，MySQL 被收構之後，Oracle 在MySQL上的投入不斷的加強，優化器、InnoDB、複製都推出了很多功能，如GR、多源複製、並行複製、優化器的重構、Undo空間的線上縮小、InnoDB的效能優化、加密表空間等，這些都是解決使用者問題的實際行動，Percona的開發也有很大一部分是基於 Oracle MySQL 來做的。
賀春暘：如果你想與官方MySQL版本儘量保持緊密，並且想獲得更好的效能、運維工具和有用的特性，那就選擇Percona。如果你覺得MariaDB對服務層的大量修改更快、更優，或者想要更廣泛的儲存引擎，比如Spider分庫分表引擎，那就選擇MariaDB。
Q5：MySQL 的認證考試值得考嗎？含金量有多大？
楊建榮：MySQL的認證目前只有MySQL OCP，目前和Oracle OCP相比，資料和套路都會少一些。考這個認證，你得明白幾件事情：
- 認證裡的內容和工作的內容還是有一些差別的，在MySQL裡面尤其如此，因為開源的方案非常多，很多優秀的工具不僅僅是官方的；
- 考過了認證不一定代表了你是一個數據庫專家，因為實踐出真知，很多技能都是在工作中培養和鍛煉出來的，考試有分數控制，達標即合格，而工作中99%的努力加1%的錯誤那就是失敗；
- 考取認證不能指望企業給你升職加薪，如果有的話，那麼恭喜你；
- 學習的過程相比考試結果來說，對自己的啟示意義更大，因為拿到認證是對你學習過程的肯定；
- 最後一點MySQL OCP報名費相比Oracle OCP低不少，價格還算親民。
賀春暘：MySQL DBA職位門檻較高，通常需要工作經驗為3年以上的，考取認證並不是必須的，其含金量不大。
李季鵬：認證只是一個門檻，一個介紹自己時精煉的關鍵詞，實際上並不能等同於技術水平的真正高低。MySQL認證分為開發與管理，個人建議可以分別視為自己在這兩條線路上學習掌握程度的一個檢驗手段，無需過分看重，也沒有必要完全看輕。
趨勢篇
Q1：隨著MySQL功能的不斷完善，其體積也愈發龐大，你是否擔心其未來會類似大型商業資料庫，不再是“小而美”的代表？
張青林：沒有這方面的擔心呢，無可否認，編譯後的 mysqld 檔案越來越大，但並不影響 MySQL 的發展， 主要表現在以下幾個方面：
- MySQL 提供了更多更好的選擇，也是對使用者的一種負責行為；
- MySQL的程式碼質量從5.5、5.6 、5.7的版本迭代中可以明顯看到程式碼質量越來越高，易讀性越來越好、模組化越來越強；
- 專業的測試團隊也是質量的保證；
所以，我覺得沒有使用者會因為多了幾十M的空間而嫌棄更好用的版本吧，我覺得關注的重點不應該是小而美，而是軟體質量和易用性。
虢國飛：主要還是看場景需求，對於網際網路公司來說，強調的是高可用性，出問題能儘快恢復，不大可能把大把的應用或者資料放到一個籃子裡面，否則出問題影響比較大，恢復起來也會比較複雜緩慢；但因為現在很多分散式部署的DB比較零散，量大了之後維護起來比較麻煩，也可能有部分需求是需要做一些遷移整合的，不過這些只是區域性不是整體。
我覺得現在大家更關注的是如何實現自動化運維、叢集自動化和動態的擴縮容等方面，如果能通過技術把運維複雜度降低，管理再大的量其實都不是問題，現在很多開源產品也在往自動維護和動態擴縮容這方面攻關了。
賀春暘：不用擔心，您可以切為MariaDB。只要移除MySQL，然後安裝MariaDB。你的所有工具，連線程式都可以正常執行。升級到MariaDB，你也不需要進行一次匯出和匯入，資料格式MariaDB是相容的。
另外就是因為MySQL不能支援線上的擴容、HA，必須藉助第三方工具來做，不過好在5.7版本推出MGR ，Percona推出的PXC在很大程度上緩解了HA 方面問題。
賀春暘：主要是官方缺少分庫分表的解決方案。MariaDB官方提供了Spider引擎作為解決方案，但目前還沒有正式GA。所以涉及非事務強一制的業務，如LOG資訊等，通常是放入MongoDB裡，通過其自身的自動分片功能實現對資料的擴容。
Q3：你是如何看待資料庫中間層(例如Cobar、Atlas等)與資料庫的關係？
楊奇龍：準確一點的說是資料庫中介軟體，它們是資料庫服務的一種輔助，藉助資料庫中介軟體，資料庫可以具有分散式、讀寫分離、負載均衡、連線池、訪問控制等等功能，資料庫業務系統上具備更強大的功能和支撐能力。
中介軟體在一定程度上解決了單機資料庫系統容量方面的限制，可以通過讀寫分離方式或者水平拆分的方式整體提升資料庫的吞吐量。
另一方面中介軟體在資料分佈上利用shardingkey將資料獨立開，對於聚合類的需求是一種障礙。還有當前的資料庫中介軟體對於跨庫分散式事務很難保證不同資料庫分片的資料一致性問題。這些都需要開發在使用中介軟體的時候注意下規避。
虢國飛：中介軟體目前在MySQL資料庫橫向擴容方面作用很明顯，當然不止侷限於此，我們公司的DAL中介軟體就做了很多的功能，比方連線池、分片路由、限流、熔斷、加密保護等，這些功能不僅能支援資料庫的橫向擴容，還有效保障了資料庫的安全，所以說中介軟體和資料庫目前是很多公司的黃金搭檔。
韓鋒：這些中間層產品，是為了彌補資料庫的功能缺陷或效能、容量不足才出現的。在一定階段，確實解決了企業的實際需求。當我們也看到，其對應用開發還無法做到完全透明，整體架構的複雜度是提高了。從長期來看，分散式資料庫勢必會從根本解決上述問題，到時這些中間層產品也就沒有使用意義了。
Q4：你所在的公司是否有成熟的MySQL運維平臺？如果是，DBA在傳統運維類工作逐步萎縮的情況下，選擇什麼方向來發展？
虢國飛：我覺得一個公司的運維平臺發展基本有幾個階段：
- 首先是大家使用開源產品，但是發現有很多的不足，想要的功能沒有；
- 於是進入第二個階段，自己編寫一些指令碼來彌補這些不足，但是當規模越來越大的時候，發現元資料和資料變更的維護變得越來越困難，而且很容易搞錯（一旦弄錯可能出現大問題），這個時候運維平臺就必須得上馬；
- 進入第三個階段，通過運維平臺整合大家的指令碼，閉環元資料和資料狀態的變更，保障資料準確性，同時對複雜的架構進行遮蔽，讓操作的人能儘量簡單，目前我們就處於這個階段（當然有些內容還在完善中）；
另外，其實不止是DBA，整個運維體系都在做轉變，傳統的玩法效率低、重複工作多，已經不適用網際網路公司高速度、快節奏的發展了，所以說DBA工作內容需要轉變，思想也需要轉變，應該向著如何快速交付、提高資料庫整體穩定性、高效率運維、打造適合更多適合業務需要的資料庫產品方案，甚至給研發輸出資料架構方案等這些方面發展，開始往前走，這樣價值能更大（傳統DBA往往是沉在最後面，領業績的時候沒有人影，只有出問題的時候才出來背鍋）。
韓鋒：公司目前有資料庫運維平臺，當然還沒有覆蓋所有運維需求，但也大幅度減輕了DBA的工作負擔。傳統運維類的工作，確實在不斷萎縮之中。在這種情況下，DBA的發展可朝以下方向努力：
- 架構、優化方向從事資料庫架構、結構設計，效能、語句優化等方向工作。
- DevOps方向從事和資料庫運維相關的開發類工作。
- 業務方向結合業務特點，分析如何利用資料庫更好的滿足企業發展。
- 資料管理方向脫離資料庫層面，從更高的角度考慮公司的資料管理、治理類工作。
張青林：騰訊有很成熟的MySQL運維平臺，這簡化了DBA 的運維服務，提高了DBA的幸福生活指數。DBA 的運維工作較之前會少一些，可將多餘的時間投入到MySQL其它的相關工作當中，轉向研發型運維，如：
- 故障的自動化處理，自動分析錯誤日誌並預警；
- MySQL 線上壓力測試與回放；
- 利用審記來實現秒級監控等；
- ……
只要是和資料庫相關的，自己又有想法的，都可以和研發一起討論並嘗試。
未來篇
Q1：你認為未來雲會成為資料庫的主要載體嗎？如果是，它會對傳統DBA帶來什麼樣的衝擊？
虢國飛：個人認為使用雲是一種趨勢，它能在資源交付、穩定性和成本方面為企業提供很好的支撐，隨著雲產品的不斷完善，目前已經可以滿足大部分中小企業的需求，中小企業完全可以省心省力地使用雲（不用關心資源和維護，而專心做業務）。
不過現在公有云產品對一些要求比較高、量大的企業還不是特別合適（未來也許也不是問題）；因此DBA也不要再固守傳統的城池，應該放開心態來面對這種變化，更多的把重心往上面所說的方向上轉，做資料架構、儲存方案，這樣價值更大。
韓鋒：未來雲一定會成為資料庫的主要載體。人們可以像使用水、電一樣，使用資料庫服務。傳統DBA，從事的基礎運維類工作基本不復存在。DBA，要麼繼續深研資料庫技術，在雲服務商或乙方服務類公司發展；要麼傾向於架構、開發、優化方向發展。
李季鵬：個人理解，公有云為成為初創企業和網際網路企業的主要使用者；傳統企業從各個角度考慮只會考慮私有云或者混合雲方案。這樣的場景，與以前小企業不需要DBA，大企業DBA忙不過來的基本情況其實沒有本質區別。引入雲，DBA需要及時更新知識儲備，以應對各種新技術引入的挑戰。
Q2：你是如何看待分散式資料庫的未來前景？未來哪些場景會優先考慮此類方案？
虢國飛：自從Google Spanner F1 釋出後，分散式資料發展很快，跟隨者國外有CockroachDB，國內有TiDB，兩者都發展比較火，從原理上來講也確實能解決不少業務場景的痛點，如資料一致性要求高（多副本分散式協議保障一致）、資料容量很大、動態擴縮容、容災要求高、跨機房、跨地域的部署需求等，這類需求一般是對一些大公司、大數量和資料質量要求很高的公司才會有，一般中小公司也玩不起來，因為分散式資料庫部署的成本還是比較高的（一般最小配置就是好幾臺機器），而且運維難度也比較大（沒懂行的人出問題基本搞不定），目前很多分散式資料庫產品在效能和穩定性方面還需要進一步經過驗證，一旦技術穩定後，應該還是比較有市場的。
韓鋒：非常看好其發展前景，特別近兩年來，已經有很多公司做了這方面的嘗試。隨著分散式思想、演算法的成熟及硬體技術的發展，未來分散式資料庫將逐步成熟、完善，成為主流的方案。作為早期嘗試，可在資料安全要求相對較低的OLAP領域嘗試使用。
Q3：在很多公司，DBA正在越來越多地從事DevOps類工作，你的看法是？
楊奇龍：
- 首先，因為生產效率正在逐步提高，DB系統需要自動化，開發需要自助化解決工作生產過程中的問題，因此具備DevOps能力是一個非常合理的發展趨勢。
- 其次，雲端計算的普及以及大公司、第三方服務公司將專家級別的運維平臺產品化之後給DBA帶來的挑戰就是：純粹只會維護資料庫的DBA生存空間越來越小，DBA要麼具備開發能力而且能夠將運維經驗落地，要麼具備足夠的資料庫周邊產品設計能力，比如設計出產品解決開發日常遇到的痛點。
- 最後 ，俗話說藝不壓身。瞭解什麼是服務化、Restful API 、微服務，什麼是MVC及常用的Web 框架、併發訪問控制等開發知識，能夠更流暢地與開發溝通，站在他們的角度思考問題，從而更好地使用資料庫。
文章來自微信公眾號：DBAplus社群