您如何知道何時升級 RDBMS/SQL 數據庫基礎架構？要遵循哪些指標？
在我的具體情況下，我剛剛將我的輔助項目部署到 AWS 並使用 AWS 免費套餐中的 AWS MySQL Tier 2 Micro 實例；
https://aws.amazon.com/ec2/instance-types/t2/
它具有：20 GB 儲存、1 GB 記憶體、1 個 vCPU、6 個 CPU 積分
所以現在我有一堆可以在 AWS 中遵循的指標；
作為開發人員，我知道使用 SQL 數據庫的基礎知識，但作為 DBA（數據庫管理員）和託管它們，我知之甚少，但我想學習基礎知識。
所以我的問題不是 AWS 特定的問題（它也與 Google Cloud Platform 和 Microsoft Azure 有關），而是一個更廣泛的問題；
- 作為 DBA，您如何知道何時升級 RDBMS 基礎架構？
- 您應該遵循哪些關鍵指標以及為什麼要知道何時應該嘗試升級您的基礎架構？
- 任何新的 DBA 都應該了解哪些基礎知識？
不幸的是，這不是一件簡單的事情。涉及到很多黑魔法和經驗，因為你正在處理一些不同但強耦合的問題。首先，您嘗試確定您的基礎架構是否需要更新以處理應用程序1，如果應用程序需要更改以優化它2，兩者的混合3 ，或者您是否需要在步驟4中重新架構兩者。
1：在問題上扔硬體
2：更好的索引，修復反模式以改進這些索引的使用，等等
3：當應用程序有優化收益，但仍需要硬體升級以達到所需的性能時
4：切換到廣泛的擴展模型可能需要同時更改基礎架構和程式碼作為同一個宏偉（重新）設計的一部分
如果您對應用程序幾乎沒有控制權，或者您相信它已經盡可能地自行優化，或者您希望盡可能地不去管它，那麼您可以使用基礎架構更改，其中在這種情況下，有一些更嚴格的規則：如果您經常訪問磁碟/網路以進行讀取活動，則考慮升級 RAM 的數量，如果您在磁碟/網路 IO 上阻塞以進行寫入活動，那麼性能更好的儲存層可能是需要，如果您的 CPU 資源總是很忙但其他資源較少，那麼這可能是升級目標，但請注意分析負載是否主要是並發的（如果您有少量長時間執行的 CPU 繁忙任務，那麼速度會更快核心有用，如果您具有高並發性，那麼更多的核心可能會更有幫助，但請確保您有足夠的記憶體，以免它們因讀取需要處理的數據的 IO 瓶頸而餓死）。
當然，即使無法控制更改應用程序的其餘部分，您也可以通過索引更改來幫助它。
作為一般規則，您不想監控特定指標的絕對值，而是關注關鍵指標隨時間的變化。這些指標將是前端應用程序吞吐量（一般或特定操作的響應時間）、伺服器端吞吐量（每個週期的事務、平均事務長度……）和基礎設施相關（CPU 使用率、IO 繁忙/等待時間，記憶體使用）。確保您了解基線指標，這樣您就可以更直接地看到由於數據增長、並發增長導致的瓶頸，或者由於新的使用者過剩或應用程序的變化而突然出現的瓶頸。
需要的東西的指標：
- 如果您比最新版本落後 2 個以上，則該升級了。（當你落後太多版本時，升級變得更加困難。）對於 MySQL，你應該在 5.6、5.7 或 8.0 上。
- 隨著軟體的增長、數據的增長以及“使用者”的期望值的增長，您可能會發現需要更好的性能。有沒有發生過？如果它發生了，那麼典型的“解決方案”涉及調整應用程序，而不是硬體，不是作業系統，很少是軟體版本。
- 以我的經驗，slowlog 不僅有關於是否做“某事”的最佳資訊，還有關於將注意力轉向何處的線索。
- 觀察磁碟使用情況。但是您需要一個跨越數週或數月的圖表。這樣，您可以預測何時會用完磁碟空間。添加磁碟空間？清除舊日期？壓縮？ETC。; 有多種可能的行動。
虛假指標：
- 對於硬體而言，過去二十年來唯一的實質性變化是磁碟從 HDD 轉向 SSD。但這也不是“必要”的改變。也就是說，如果您遇到性能問題，則幾乎不需要升級。
- 每個版本的硬體、作業系統、MySQL 等都帶來了一系列“更好”的東西——更快一點，更好地處理一些晦澀的案例等。但是，一般來說，每個“改進”都需要不到 1%的系統。因此，如果沒有確定升級特別滿足的特定需求，升級可能是浪費精力。
- 您提供的圖表告訴我，您的系統遠未達到飽和。
- 1% CPU？這聽起來像是由作業系統和監控任務引起的背景噪音。有什麼在執行嗎？IOP 同上。
- 讀取延遲 < 1ms？一個人不會注意到不到幾十毫秒。