MySQL DBA 技術難度低為什麼工資比 Oracle 高？

編輯手記：

之前在知乎上出現了一個很熱的帖子，話題是“MySQL DBA技術難度低為什麼工資比oracle高？”，這個話題很快引起了熱烈的討論。從回帖的情況來看，大部分人幾乎都預設了MySQL DBA工資的確高這個事實，那麼原因是什麼，我們節選MySQL專家劉偉的回帖跟大家分享。

以下是他回帖的原文：

主要有以下兩個原因：

1、市場供需關係

2、技術要求相對高

這兩個因素一直沒有得到改善，導致現在市場的行情是：招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都聞到了一股淡淡的憂傷，關於薪資的不公平現狀，你怎麼看，歡迎留言給出你的想法。

轉載自 | 資料和雲

作者 | 劉偉