MySQL RAID 配置
我將 4 個 10GB 磁碟連接到 MySQL 伺服器並使用 RAID 0：
但 MySQL 的性能仍然相同。我是否必須更改配置
my.cnf才能讓 MySQL 知道 RAID 0？這是我的
mount結果：
這不是開發箱，它是我的生產伺服器。我曾經在 AWS 上擁有 MySQL 伺服器，但現在我使用的是 Azure，I/O 確實對 MySQL 造成了傷害。
我不是伺服器管理員專家，但我想在這裡解決我的問題，一位顧問建議我做 RAID 0。
我正在使用 newrelic 來測試我的性能。它顯示了 MySQL 有多糟糕，我的伺服器是 8 核和 14 GB Azure 伺服器。
首先：除非這是一個複制從機、開發盒或類似設備，在最壞的情況下可以很容易地從其他來源重建，否則不建議使用RAID0 。它提供了良好的性能，但可能會嚴重降低可靠性：如果您的四個驅動器中的任何一個出現故障，那麼整個陣列都會烤麵包。
在新資訊後編輯：從快速搜尋中可以看出，人們確實在 Azure 上推薦 RAID0，假設由於平台中的冗餘，底層（虛擬）磁碟是可靠的。我不相信這是一個好主意，雖然我沒有使用過這個平台，所以可能不是在那裡發表評論的最佳人選。
其次：完全不了解您的數據大小、基本資料結構（對於在基準測試中測試的部分）、讀/寫負載模式、伺服器規格的其他詳細資訊（RAM、CPU、…）、您的 mySQL 配置（開箱即用或進行了一些調整？）（如果開箱即用，哪個盒子？），您如何測試性能以顯示它是相同的，等等，我們在性能方面無法真正幫助您一點也不。
我們可以說的唯一一般情況是，如果您的性能主要受 CPU 資源限制，那麼 RAID 不會有任何區別，因為這只影響 IO 性能。
第三：您沒有顯示該 RAID 卷是否作為文件系統或 LVM 安排的一部分安裝在任何地方。您是否已這樣做並告訴 mySQL 將數據儲存在該數組上？
雖然可以在數據庫級別完成一些手動操作（移動表空間等），但 MySQL 的大多數設置對儲存層是透明的，這意味著您不需要做任何事情來利用襲擊。
雖然 RAID 0 可以為您提供更好的讀寫理論吞吐量（代價是有 4 個獨特的故障點），但優化基本上取決於磁碟綁定。如果您的工作集主要安裝在 RAM 上（並且有 10GB 的磁碟，這不足為奇），那麼優勢將是微乎其微的。它還取決於所使用的儲存引擎——例如，MyISAM 往往最終會將其所有使用的塊記憶體在密鑰緩衝區或文件系統記憶體上，以犧牲其耐用性為代價。
我建議您執行純磁碟 IO 測試（使用 IOzone 和 Bonnie++ 等工具）以確保一切按預期工作。第二：問問自己 RAID 0 是否是降低延遲/提高吞吐量的正確方法。