DBA不僅僅是管理資料庫--也要管理中介軟體

看到這個標題可能覺得我在亂說，其實很多中介軟體作為資料庫的上下游，它們的穩定取決於資料庫的穩定。這裡我主要指的是SQL。

很早之前我說開發的主題語言其實更多的是SQL(這裡並沒有說Java不重要的意思)，只是Java中並沒有太多的業務邏輯。真正的業務邏輯主要還是在SQL中體現的。說的直白一點是如何寫資料，如何讀資料。

我現在工作不太做資料庫安裝、備份等。更多的是看看開發這裡的問題。用工具開啟開發程式碼看到後很多專案一半以上是SQL，甚至這個比例最高能到70-80%。所以更加證明了我之前說的。

每當說到這裡非資料庫出身的開發會質疑我誇大資料庫的作用。因為我也見過有人是把資料全部拿走，然後自己在程式中做各式各樣的運算等操作。這樣顯得和資料庫沒什麼關係。其實這個作用自在人心吧。

但是在一次次資料庫問題甚至故障後，越來越多的開發人員意識到我說的是對的。而我也在一些顧問和問題中發現，其實SQL的影響不僅僅是資料庫。多次中介軟體(這裡指的是Tomcat的JVM和訊息佇列等)的問題(OOM或者是頻繁Full GC)也是由於SQL造成的。因為一次取的資料太多，資料庫把資料明細這種幾十萬甚至上百萬的資料送到相關環節，這些環節一下處理不了這些資料，就發生了OOM或者是頻繁Full GC。

這裡可能是一次性取很多資料，也可能資料看上去不對但是資料的物件很大。總之是資料佔據空間很大，導致了問題。

上週一個開發主動找我說。他們的JVM中問題80%都是Full GC，而這些最後發現全是SQL導致的。就相關問題找我諮詢解決方案。這說明越來越多的開發人員開始覺醒了。這真的是好事情。

我想起從前我在一個單位，和一個開發說你這樣寫不對，有什麼什麼問題。結果大家應該能猜出來，誰理我啊?但是後面有一天，那個開發找我問問題，問的還是比較深刻的問題。後面工作時遇到問題就來問我。我很好奇怎麼會有這樣的改變。後來我才得知他去一些比較好的公司面試，技術面的問題就是我平時說的。結果他因為不知道，錯過了機會。回來以後真的是發憤圖強後，然後果然去了比較好的企業，而且還換過公司。現在收入應該增加不少了。

我第一家公司小，但是當時管研發的都是70後。招聘看的是計算機知識、演算法、資料庫，最後看程式設計。招聘的開發人員真的素質都很高。可能幾個人就做一個大專案。

現在的招聘是隻看程式設計(用什麼框架)和技術棧和參與專案。我也遇到過問開發這個資料從哪裡來?答：不知道我調介面。再問這個資料去哪裡?答：不知道我調介面。你知道為什麼要用以及怎麼用Redis，為什麼要用以及怎麼用ES嗎?答：不知道我調介面。

對開發易用是好事，但是開發也應該知其然和知其所以然。當然如果每個都說精通原始碼的那種瞭解我覺得是過了。我個人覺得尺度應該是能知道問題在哪裡?比如開發人員知道是資料庫這裡問題和中介軟體這裡的問題。然後知道是什麼原因導致的就行了。剩下的交給專業資料庫人員來解決，給出解決方案就像。

管好資料庫和中介軟體是DBA(administrator)到DBA(architect)的階段。