mysql 數據庫伺服器的垂直擴展是個好主意嗎？
我操作 mariadb/mysql 數據庫伺服器，我不想陷入管理多集群數據庫伺服器的問題，我可以在需要時訪問巨大的 CPU 和 RAM 和儲存
所以我對經驗豐富的專家數據庫管理員的問題是垂直擴展是否足夠好？是的，只要數據受到保護，停機時間就可以了
那麼我在執行高達 512GB 記憶體和 128vCPU 之類的數據庫時會遇到什麼瓶頸？像 2TB 的 SSD 儲存？
這比我們說的像一個 8 集群 mariadb/mysql 數據庫一樣執行，每個集群有 64GB 記憶體、16vCPU 和 256GB SSD 儲存有什麼好處？
是的，我知道 iops，但我的意思是有很多 redis 記憶體，我認為也可以減輕這部分的壓力
幾乎有越來越強大的 CPU 和伺服器可以在一台機器上打包很多東西..不像幾年前那樣不可能或至少很容易..現在可以打包幾 TB，TB（不是單機記憶體的錯字）
請發送您的建議和提示謝謝！！！
“你不能把硬體扔到性能問題上。” 或者，更確切地說，你不能這樣做兩次。
- 20 年來 CPU 速度沒有顯著變化。
- 核心數量增加了，但 InnoDB 在使用所有核心之前總是碰壁。
- SSD 是對 HDD 的巨大改進，但下一個飛躍還沒有出現。
- 更大的 RAM（因此 buffer_pool）進入“收益遞減”狀態。
- 乙太網每隔一段時間就會產生 10 倍的“加速”。
- 填滿 PB 磁碟需要數年時間；你不想在那之前讀取數據嗎？
- 等等
一個技巧是通過擁有多個虛擬機來虛擬化一大塊鐵，每個虛擬機都執行一個 MySQL 實例。這會在單個“垂直”縮放的伺服器上進行“水平”縮放。這至少有助於我提到的磚牆。但是你有一個巨大的、代價高昂的、單點故障。
我通常的回答是“讓我們看看我們是否可以更智能地程式”。
一個反復出現的例子是數據倉庫。DBA 來到這個（和其他）論壇抱怨他們的“報告”（一個大
SELECT的，一個大的GROUP BY）花費的時間太長。我指出了匯總表的美妙之處——10 倍的加速，10 倍的磁碟佔用空間。噗，問題解決了。 沒有任何硬體升級可以達到 10 倍。複製提供了幾乎無限的讀取擴展，幾乎是線性的。
分片（水平縮放）提供幾乎無限的縮放，幾乎是線性的，但它並不適用於所有應用程序。
我在 Vertical 中看到的最好的方法是添加足夠的 RAM 以將 I/O 綁定查詢轉換為在 buffer_pool 中執行的 CPU 綁定查詢。我經常看到 10 倍的改進。 但它是一次性的改進。也就是說，添加更多的 RAM 將不再有幫助。
所以，對於你的標題問題，我說一個響亮的No。
好的，垂直可能會有所幫助，但要注意它的局限性。