MySQL LOAD DATA INFILE：更好的伺服器，更差的性能
我正在測試 Microsoft Azure Database for MySQL 並遇到了我不理解的性能問題。
我啟動了一個帶有 1 個 vCore（2 GB RAM，“標準儲存”）的“基本”伺服器，這是他們可能的最低伺服器層。我創建了一個數據庫、一個表，並使用 LOAD DATA INFILE 導入了大約 400 萬行 (30 GB)。花了56分鐘。
接下來，我啟動了具有 8 個 vCore（80 GB RAM，“Premium Storage”）的“記憶體優化”伺服器。我重複了完全相同的任務並載入了完全相同的文件。這次花了7小時16分鐘。
更好的伺服器，更差的性能（在這個任務上）——不是我所期望的。為了確定我沒有犯錯，我重複了上述步驟，但我又得到了幾乎完全相同的結果。
我懷疑問題是記憶體優化伺服器的預設伺服器參數與基本伺服器不同，這使得此任務執行得更慢（我沒有更改 Azure 設置的預設參數）。但我不確定哪些參數是罪魁禍首。如果有人能深入了解這個問題，我將不勝感激。
伺服器基本參數： http: //pastebin.zone/wRniyPm6
記憶體優化伺服器參數： http: //pastebin.zone/phuDcZj4
這似乎是導致這種行為的原因：
根據Azure 文件，Azure 上的基本層伺服器帶有“可變”IOPS，而記憶體優化伺服器帶有固定 IOPS，它基於分配給數據庫伺服器的儲存量。
我有 100GB 分配給記憶體優化伺服器。這導致它具有 300 IOPS，與 Azure 的 3 IOPS / GB 比率一致。
據推測，Basic 伺服器上的“可變” IOPS 最終大大超過了記憶體優化伺服器的 300 IOPS。
經驗教訓：要在 Azure 數據庫上快速訪問儲存，您需要為伺服器分配大量儲存容量（即使您不需要那麼多儲存！）。