653
明明技術難度更低，為何MySQL DBA工資比Oracle高？
前幾天在知乎上出現了一個很熱的帖子，話題是“MySQL DBA技術難度低為什麼工資比oracle高？”，這個話題很快引起了熱烈的討論。從回帖的情況來看，大部分人幾乎都默認了MySQL DBA工資的確高這個事實，那麼原因是什麼，我們節選MySQL專家劉偉的回帖跟大家分享。以下是他回帖的原文：
主要有以下兩個原因：
- 市場供需關係
- 技術要求相對高
這兩個因素一直沒有得到改善，導致現在市場的行情是：招MySQL DBA難，招稱心的MySQL DBA就更難。先說一個工資議價的常識，工資水平行業內比較，是比拚技術等等可積累因素，但行業間比較，主要是取決於供需關係的。
Oracle方麵
- 這些年OCP甚至OCM都被國內的培訓機構玩殘了，在Oracle DBA的價格普遍參考證書等級的情況下，Oracle DBA的議價能力相對不足。
MySQL方麵
- 官方的OCP實際上目前看被各路互聯網公司（MySQL DBA高工資的主要來源）認同度較小（見過說考MySQL OCP算降分項的說法），業內沒有公認的標準，除了大個互聯網公司的經曆（公司level）背書，很難有個通用的等級標準，隻能自由心證，自由心證的代價就是，完全靠供需關係決定市場價格，缺人的時候，各種高價都是舍得的。DBA的圈子本身就不大，MySQL DBA的缺口是行業性的缺口，自然會讓收入水平水漲船高，市場經濟的情況下，隨著這個圈子的人越來越多（Oracle DBA轉MySQL DBA，運維幹MySQL DBA，各路培訓機構產出MySQL DBA），MySQL DBA的收入也不會一直維持在一個高水位的。
MySQL學習難度本身是很低的，實際上純粹的操作MySQL DBA的收入，比較Oracle DBA隻是因為供需關係多一點點，其實還好，並不會到一個什麼樣的比例，但如果加上一些限定條件，就很難找人了，供需關係急劇惡化導致找人的價格很難控製。
一般來說互聯網公司在招聘MySQL DBA的時候常常會附加以下要求：
1.有自動化開發經驗:有人提到規模性問題，的確在肯給高工資的DBA裏麵，自動化開發是占比很大的部分，接觸過的有30k以上的報價，這點主要因為MySQL到目前為止沒有一個公認可靠的基礎運維係統，都是各家自己造輪子。而Oracle公司產品做得好（OEM，grid mgr，ASM之類），Oracle DBA沒有這麼大的壓力或者要求。因此如果企業使用了MySQL數據庫，在招聘時，除了要求應聘者能夠熟練地自動化運維開發的同時，還需要是一個熟練的MySQL DBA，如果公司沒有配置專門的運維前端開發（實際情況看，即使有，水平也很有限，高水平前端找人難度更大）的話，連前端也需要自己做，約等於半個全棧了。
2.的確能搞定MySQL的正常運維，備份恢複，DDL變更之類:見過太多小公司的MySQL DBA誤刪數據，備份失效的事情了，這點和技術能力，責任心等方麵關係非常大，Oracle有很多機製比如flashback，回收站之類可以救火，但MySQL很多時候隻能說一句“沒救了”。MySQL是一個遠比Oracle脆弱的數據庫，“不可恢複操作”遠比Oracle容易遇到得多，怎麼在操作的時候，保證操作的安全，是個非常麻煩的問題，尤其是MySQL那種文檔質量（不是黑，MySQL文檔已經是開源軟件中最完備的文檔之一了，但比比Oracle的文檔體係，MySQL的文檔可參考性小很多的）。
3.不要求能改代碼，但至少對MySQL的各種實現機製非常熟悉並且能用於工作:最基本的要求是C,C++熟練，更進一步能自己修代碼還不會出幺蛾子的，都被大廠收了做內核開發，那個供需關係更緊張也不是傳統定義的DBA，這種可以排除出所謂MySQL DBA的定義，但即使是作為MySQL DBA，如果出現一個代碼方麵的bug，比如程序代碼死鎖（不是事務死鎖，而是代碼bug，mutex死鎖）的時候，總不能每天想著找大廠熟人問一個未必靠譜的答案吧。
4.對linux有充分的了解:比如APUE，CSAPP講到的東西都明白的地步，包括SSD優化在內的環境優化，這就變成了一個綜合話題。首先得承認硬件的進步對MySQL的優化要求沒有那麼強，或者在一定瓶頸前沒有什麼要求，但cpu，內存，網絡，存儲，文件係統等等方麵的要求，也並不是可以純粹無視的要求，畢竟這個所謂的瓶頸並不難達到（我自己的數據是3到5倍的性能差距，未必能作為通用標準）。
5.對整個數據庫體係（包括緩存，隊列，大數據）都有深入了解，而不隻是會安裝的程度:如果說linux運維包打天下是小公司的做法，那麼在規模沒有到相當大程度的公司，大數據相關的玩意，幾乎一定會被交給DBA的，比如HBASE，REDIS，SPARK，KAFKA，MONGODB，ElASTIC SEARCH 這些，畢竟外行來看，反正都是數據庫。但實際上，RDBMS與NOSQL（包括NOSQL相互之間）的運維差別非常大，而且大數據體係的玩意每年都有流行款，學習壓力其實非常大（目送前端的同誌遠去~~每周一個不兼容老版本的新版本，每個月都有框架大新聞）。
6.SQL優化可以根據業務形態提出適當建議:都知道MySQL優化器很蠢，那麼在這種情況下，怎麼做好SQL優化本身就是問題。比如我的一個標準是，三個表之內的表連接，可以手寫執行計劃，並可以根據提出的不同數據分布給出更合適的執行計劃以及更合適的SQL寫法。實際上分庫分表是這個下屬的一個要求，比如在分庫分表情況下，如何最快地操作數據多表聚合，這點延展開來，到中間件的優化或者類中間件使用方式的優化（包括SOA（現在有人喜歡叫微服務）體係下的數據聚合），都是需要了解，有實際實踐的，再多一點的，就是作為中間件開發乃至分布式數據庫開發（C/JAVA/GO）需要知道的了。
滿足這些條件的，一般都會拿到不錯的議價，但這種成交造成的“高水位線錯覺”，會讓普通操作DBA對收入有更高的期望，導致低議價的減少，讓市場成交價更高。
DBA的學習周期（培訓班那種不算），一般是兩到三年，考慮到MySQL DBA正經起飛，也就是這兩年的事情，估計等個兩三年，市場上人數更多的時候，MySQL DBA的收入應該是會有所回落的。當然，我說的是純粹的操作DBA，高技術水平的，無論是Oracle DBA，還是MySQL DBA，或者PostgreSQL DBA，DB2 DBA等等等等DBA的收入水平，不會有大的變化或者隻會更高，這個細分市場的供應速度，是遠遠低於需求增長速度的。
看到這裏，可能各位Oracle DBA都聞到了一股淡淡的憂傷，關於薪資的不公平現狀，你怎麼看，歡迎留言給出你的想法。
來源：數據和雲 作者：劉偉
最後更新：2017-04-01 17:13:52