本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

將資料匯入 MySQL 資料庫執行個體

您可使用多種不同技術，將資料匯入 RDS for MySQL 資料庫執行個體。最理想的做法需視資料來源、資料量，以及作業是屬於一次性或持續性匯入等條件而定。如要連同資料一起遷移應用程式，也需考量您願意承受的停機時間。

概觀

將資料匯入 RDS for MySQL 資料庫執行個體的各種技術如下表所示。

資料匯入考量

以下說明將資料載入 MySQL 的其他相關技術資訊。這些資訊適合熟悉 MySQL 伺服器架構的進階使用者參考。

二進位日誌

相較於關閉二進位日誌，一旦啟用此功能，載入資料會導致效能減損，且需要額外的可用磁碟空間 (最多可能需要原本的四倍大)。至於效能折損的程度與所需的可用磁碟空間，則與載入資料的交易大小成正比。

交易大小

交易大小在 MySQL 資料載入作業中扮演重要角色。交易大小主要會影響資源耗用情形、磁碟空間利用率、恢復程序、復原時間及輸入格式 (一般檔案或 SQL)。本節會說明交易大小如何影響二進位日誌，並解釋為何要在大型資料載入期間停用此功能。如前所述，設定 Amazon RDS 自動備份保留期可啟用及停用二進位日誌。非零的數值會啟用二進位日誌，而零則會停用此功能。我們也會說明大型交易對 InnoDB 的影響，以及為何需要盡量縮減交易大小的原因。

小型交易

若為小型交易，二進位日誌會將載入資料所需的磁碟寫入次數加倍。此效果會嚴重降低其他資料庫作業階段的效能，並增加載入資料所需的時間。效能降低的程度有一部分取決於上傳速率、載入期間發生的其他資料庫活動，以及您 Amazon RDS 資料庫執行個體的容量。

二進位日誌在完成備份及移除前，也會佔用與載入資料量約莫相等的磁碟空間。幸好，Amazon RDS 會頻繁備份並移除二進位日誌，將佔用的磁碟空間減至最少。

大型交易

若啟用二進位日誌，大型交易會耗用 IOPS 與磁碟空間，對效能造成的影響更可達 3 倍。這是因為二進位日誌快取會溢出至磁碟、佔用磁碟空間，導致每次寫入時會發生額外的 IO。在交易遞交或轉返前，快取不會寫入二進位日誌，以致於隨著載入資料量的大小佔用相應的磁碟空間。交易遞交後，快取必須複製到二進位日誌中，導致磁碟上有第三份資料複本。

正因如此，相較於停用二進位日誌，至少要有三倍大小的可用磁碟空間，才能在啟用此功能的情況下載入資料。舉例來說，單次交易有 10 GiB 的載入資料，載入期間會至少佔去 30 GiB 的磁碟空間。資料表佔用 10 GiB + 二進位日誌快取佔用 10 GiB + 二進位日誌本身佔用 10 GiB。在建立此快取檔案的工作階段終止，或另一筆交易的工作階段再次填滿其二進位日誌快取之前，快取檔案都會保留在磁碟上。由於二進位日誌在備份前必須保留在磁碟上，因此要釋放額外的 20 GiB，可能需要一些時間。

如果使用 LOAD DATA LOCAL INFILE 命令來載入資料，且必須從一個在本次載入前製作的備份復原資料庫，還會建立另一份資料複本。復原期間，MySQL 會擷取二進位日誌的資料，放入一般檔案中。MySQL 接著會執行 LOAD DATA LOCAL INFILE 命令，方式就如同原交易一樣。但是，對資料庫伺服器來說，這次的輸入檔案是本機檔案。若繼續執行前述範例，除非有至少 40 GiB 的可用磁碟空間，否則復原作業就會失敗。

停用二進位記錄

盡可能在大型資料載入期間停用二進位記錄功能，以避免資源負荷與額外的磁碟空間需求。在 Amazon RDS 中停用二進位日誌很簡單，只要將備份保留期的數值設為零即可。如要使用這個方法，建議您在載入前，先拍攝資料庫執行個體的資料庫快照。如此一來，如果有需要，您就可以快速且輕易地復原載入期間所做的變更。

載入完成後，請將備份保留期設回適當 (非零) 的數值。

如果資料庫執行個體是僅供讀取複本的來源資料庫執行個體，則不可將備份保留期設為零。

InnoDB

本節資訊會提供強而有力的論述，說明為何要在使用 InnoDB 時，盡可能縮減交易大小。

Undo (復原)

InnoDB 會產生復原，以支援交易轉返與 MVCC 之類的功能。復原會存放在 InnoDB 系統資料表空間 (通常是 ibdata1)，並一直保存到清除執行緒將其移除為止。清除執行緒的作用範圍無法超過最早有效交易的復原，因此在交易遞交或完成轉返前，都能有效封鎖。如果資料庫在載入期間同時處理其他交易，即使這些交易皆已遞交，且沒有其他交易需要因為 MVCC 而復原，這些復原也會累積在系統資料表空間中，並且無法移除。這種情況下，所有交易 (包含唯讀交易) 只要存取任何交易 (不僅是載入交易) 變更的任何資料列，速度都會變慢。如果不是因為載入交易長時間執行，變慢的原因就是交易掃描了可能早已清除的復原。

復原會存放在系統資料表空間，而系統資料表空間的大小永遠不會縮減。因此，大型資料載入交易可能會造成系統資料工作表變得無比龐大，佔用磁碟空間，且若未從頭重建資料庫，將無法回收這些空間。

轉返

InnoDB 已針對遞交作業完成了最佳化。轉返大型交易需要很多時間。在某些情況下，執行 point-in-time 復原或還原資料庫快照可能會更快。

輸入資料格式

MySQL 可接受以一般檔案或 SQL 為傳入資料的格式。本節會指出兩種格式的幾項重要優點及缺點。

一般檔案

在交易盡量縮減大小的情況下，以 LOAD DATA LOCAL INFILE 命令載入一般檔案會是最快速且成本最低的資料載入方式。相較於以 SQL 載入相同資料，一般檔案需要的網路流量通常較少，如此不僅可以降低傳輸成本，而且因為資料庫負荷降低，載入速度也會快速許多。

整併成單一大型交易

LOAD DATA LOCAL INFILE 命令會將整個一般檔案視為單一交易，一次載入。這不見得是件壞事。如果可以盡量縮減個別檔案的大小，此方式就有許多優點：

請注意

交易大小增加時，LOAD DATA LOCAL INFILE 命令的優勢會迅速減少。如果無法將大型資料集拆分成較小的資料集，則 SQL 或許會是較好的選擇。

SQL

SQL 具備一項一般檔案所缺乏的主要優點，亦即 SQL 容易將交易大小維持在較小的狀態。然而，相較於一般檔案，SQL 需要的載入時間較長，而且一旦失敗，很難判斷要從哪裡繼續載入。舉例來說，mysqldump 檔案無法重新啟動。如果在載入 mysqldump 檔案時發生錯誤，檔案需要修改或替換才能繼續載入。替代方案是還原至載入前的時間點，然後在修正失敗原因後重新執行檔案。

使用 Amazon RDS 快照擷取檢查點

如果您的載入作業會持續數小時甚至數天，除非您可以擷取定期檢查點，否則載入時不使用二進位日誌的話，情況恐怕不太樂觀。此時，Amazon RDS 資料庫快照功能就可派上用場。資料庫快照會建立資料庫執行個體的 point-in-time 一致副本，以便在當機或其他事故後，將資料庫還原到該時間點。

若要建立檢查點，只要拍攝資料庫快照即可。您可以移除任何先前為做為檢查點而拍攝的資料庫快照，這不會影響耐用性或還原時間。

拍攝快照的速度也很快，所以經常執行檢查點作業並不會增加太多載入時間。

減少載入時間

以下額外提供幾種可減少載入時間的秘訣：