資料庫管理-第142期 DBA？DBA！（20240131）

作者：胖頭魚的魚缸（尹海文）
Oracle ACE Associate: Database（Oracle與MySQL）
網思科技 DBA總監
10年資料庫行業經驗，現主要從事資料庫服務工作
擁有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等認證
墨天輪MVP、認證技術專家，ITPUB認證專家，OCM講師
圈內擁有“總監”、“保安”、“國產資料庫最大敵人”等稱號，非著 名社恐（社交恐怖分子）
公眾號：胖頭魚的魚缸；CSDN：胖頭魚的魚缸（尹海文）；墨天輪：胖頭魚的魚缸；ITPUB：yhw1809。
除授權轉載並標明出處外，均為“非法”抄襲。

本來說這個月不寫文章了，先是想了想一月寫了13篇，13有點不吉利，但這不是重點，重點是今天晚上（1月31日）OSC又雙叒搞了一個大招，需不需要DBA。哎，想來還是寫寫吧，作為個DBA，我肯定是站DBA的（至少在AI幹掉所有人工作之前），但我又不是完全站某些人理解的那種片面的DBA。下面的文章內容應該會比較混亂，就一個章節。

正文

寫程式碼的人，也就是開發人員，他們的能力真的是參差不齊，尤其是很low的開發，一條SQL就能把資料庫幹趴，我就沒搞懂為啥這種語句在RDS上就不是問題了，RDS也是資料庫也會跑掛，掛了雲後臺DBA很多時候也會介入。這種SQL不稽核直接上線，業務掛了帶來的損失大多數時候是比不上極 速迭代帶來的收益，畢竟口碑這種東西建起來難毀著挺快的。

說真的最佳化一條SQL，往往不能解決問題，源自於整個業務邏輯的問題，有時候其中某條SQL快了之後反而會引起業務流程一系列問題反而更慢。我從來不認為我最佳化了單條SQL就是能力多強，而是我在不斷資料庫管理過程中，逐漸熟悉業務後，與開發人員一起，帶著他們從整個錯誤的邏輯層面去最佳化業務。

資料量不同，資料庫和語句的執行狀態是完全不一樣的，所以不要拿那些小到不得了的資料庫來對比大庫，也不要說大庫沒有存在的必要，因為業務場景不同，也不要拿全點查的業務來對比天生偏向HTAP的業務。

業務場景決定了你會產生何種型別的資料，這些資料應該怎麼存放，存放方式又決定了資料使用方式，別總說DBA濫用關係型資料庫，我也是略懂各類NoSQL資料庫的，也會根據業務情況建議使用不同的資料庫，甚至建議僅維持一些資料的狀態（不落庫）。再說了Oracle和不少關係型資料庫也在走向融合的道路，簡化資料的使用方式。

由於我服務客戶的原因，全都是自建IDC，不能上公有云，頂多算是私有云（我這管理資料庫全是物理機）。我也能做到足夠的高可用性，也能做到業務出現問題（影響資料庫效能時）先敵發現、先敵反饋、先敵處理（絕對的細粒度監控告警，甚至很多雲上都實現不了）。

總結

我認為，業務場景決定了資料組織形態，資料組織形態又決定了該如何使用資料，這中間如何實現高效轉化，才是DBA最大的價值。
老規矩，不知道寫了些啥。