注明：本文以 Joomla 網站導入為例，其他程序，只需相應修改路徑既可以。

常用的 MySQL 數據庫恢復工具（也能進行備份操作）是 phpMyAdmin，這是一個開源、免費的工具，大多數主機商（例如 Hawkhost）都會免費提供 。相信很多站長也用過 phpMyAdmin 來進行網站數據庫的備份和恢復，確實很方便，并且有多國語言界面。不過，有一種情況可能你還沒碰到，就是當你的數據庫體積比較大時，例如 SQL 備份文件大于 2MB，甚至大于 10MB，這個時候如果你通過 phpMyAdmin 來進行數據庫的恢復，就會出錯，顯示如下的提示：

這是因為你的 SQL 文件體積太大，超過了 phpMyAdmin 的處理能力，這種情況在網絡速度比較慢的情況下尤為突出，例如站長在周末晚上8點這個網絡擁擠的時段嘗試使用 phpMyAdmin 來恢復大型 MySQL 數據庫備份，就容易遇到這種問題。

很顯然 phpMyAdmin 只適用于恢復比較小的 SQL 文件備份。對于超大 MySQL 數據庫備份的恢復，你必須換一個專用的恢復工具，那就是：BigDump！

BigDump 數據庫導入工具簡介

BigDump 是由德國人 Alexey Ozerov 用 PHP 語言開發的一個工具腳本，它只有一個文件，名為 bigdump.php（你可以改名運行）。這個文件是獨立運行的，因此與你的網站核心程序無關，不管是 WordPress，Drupal 還是 Joomla，只要你使用的是 MySQL 數據庫，都可以用 BigDump 來恢復超大的 .sql 格式備份文件。

BigDump 工作的原理也很簡單：切割分段導入。它在讀取 SQL 文件時，每次只讀取一小部分，將其導入，然后重新開始一次恢復進程，再讀取一小部分…… 周而復始，直到將整個 SQL 文件全部導入。

BigDump 數據庫恢復工具用法演示

假設我們已經有了一個 MySQL 數據庫的備份文件，名為 gate2.sql，文件大小約 150MB（這么大的文件別指望通過 phpMyAdmin 來恢復了）。數據庫字符編碼為 utf-8。我們演示一下如何通過 bigdump.php 工具將這個備份文件恢復到在線數據庫中去。

1、獲取 BigDump 文件并設置

我們下載 BidDump 工具并解壓，得到一個 bigdump.php 文件。毫無疑問，bigdump.php 文件需要設置一些參數，否則它怎么知道要導入的數據庫的連接帳號？

用文本編輯器打開 bigdump.php 文件，在大約第 38 行開始，我們設置要導入的 MySQL 數據庫連接參數。如下圖所示：

一般來說，設置好這幾項就可以了。對于某些特殊數據庫，還需要在下面第66行左右設置數據庫字符編碼。bigdump.php 文件中沒有預設這個參數，原文是：

如果你的數據庫是 UTF-8 編碼，那么此處就要修改為：

注意那個連字符要去掉。如下圖所示：

接下來將設置好的 bigdump.php 文件上傳到 Joomla 網站上，推薦上傳到 /tmp 這個臨時目錄。

2、上傳 MySQL 數據庫備份文件

現在需要將數據庫備份文件上傳到 bigdump.php 所在的 /tmp 目錄中?？紤]到文件較大，我們通過FTP 軟件 FileZilla 上傳zip 格式的文件，然后借助 Joomla 后臺安裝的 eXtplorer 資源管理器組件將其遠程解壓，在 /tmp 目錄中得到 gate2.sql 文件。

3、啟動 BigDump 工具

在瀏覽器地址欄輸入 bigdump.php 所在 URL 并回車，運行這個文件。例如本次演示是在本地測試服務器上進行，那么對應的運行網址是：

http://localhost/gate/tmp/bigdump.php

如果你輸入的 URL 正確，就應該看到如下畫面：

這就表示 BigDump 工具已經成功啟動，它在啟動時就自動掃描所在目錄中的全部文件和子目錄。如果找到 SQL 格式或者 gzip/zip 格式文件，就假設這是數據庫文件，在這些文件后面，就會顯示出相應的操作鏈接。例如在上圖中，它探測到所在目錄中有一個 gate2.sql 文件，那么針對該文件就在表格右側同一行中顯示了兩條操作鏈接，分別是“Start Import”（開始導入）和“Delete file”（刪除文件）。上圖的表格中也顯示了 SQL 文件的大小，可以看到這個備份文件接近 150MB。

在上圖中，還可以看到一個文件上傳功能，點擊那個“瀏覽”按鈕，你就可以上傳一個 SQL 文件（或其壓縮包）來進行導入。但是我們不推薦使用此功能。對于大型文件，FTP 上傳是最佳選擇。

4、運行 BigDump 導入功能

點擊上圖中的“Start Import”鏈接，就看到如下畫面：

上面這個截圖是導入開始一段時間之后所截取的，可以看出 BigDump 正在順利進行 SQL 文件的導入。表格中不僅顯示了文件大小，還顯示了已經導入的字節數及總體進度。

經過一段時間后（大約20分鐘），這個 150MB 大小的 SQL 文件終于導入結束，看到如下畫面：

原來顯示進度條的地方，現在顯示了一條消息：

Congratulations： End of file reached， assuming OK

意思是說：已經到達文件末尾，想必應該成功了。看到這條消息，你就可以完全放心了。BigDump 已經成功地將你的 SQL 備份文件導入到你所指定的 MySQL 數據庫里面了。

注意：數據庫恢復成功結束后，不要忘記刪除 bigdump.php 備份工具和你的 SQL 文件！使用 BigDump 數據庫導入工具的注意事項

1、在開始導入之前，目標數據庫必須清空

如果目標數據庫里面含有記錄，那么 BigDump 就無法導入，會報錯停止。因此請在開始運行 bigdump.php 文件之前，將目標數據庫清空（最好刪除全部內容）。

2、所用的 SQL 文件不能含有 Extended Inserts

或許很多第一次使用 BigDump 的用戶都會遭遇這個問題。這是因為 phpMyAdmin 在導出數據庫時，已經默認勾選了“使用擴展插入”。

這里的“擴展插入”就是 Extended Inserts，而 BigDump 是不能處理帶有 Extended Inserts 的 SQL 文件的。所以，在你制作數據庫備份時，必須在 phpMyAdmin 的面板上去掉“擴展插入”的勾選。如下圖所示：

3、如何使 Akeeba Backup 與 BigDump 配合工作？

我們前面推薦大家使用 Akeeba Backup 來制作備份文件。那么，可否使用 Akeeba Backup 來制作數據庫備份，然后通過 BigDump 導入？當然是可以的。不過，這里面需要一些特殊技巧。我們將在 Akeeba Backup 使用詳解 這篇教程中介紹。

4、使用 BigDump 導入仍然發生超時錯誤

這種問題多見于配置比較低的服務器，或者服務器繁忙時段。那么，你可以嘗試修改 bigdump.php 文件中的“Other settings （optional）” 這部分的 $linespersession 參數，將默認值 3000 修改得更小一些。（不過，我認為你還是換一個更好的服務器吧，例如 Hawkhost）。

5、發生 MySQL 服務器超載怎么辦？

如果服務器性能較差，在運行 bigdump.php 過程中可能會發生 MySQL 服務器超載（overrun）故障。你可以修改 bigdump.php 文件中的 $delaypersession 參數來解決。該參數讓 bigdump.php 文件在結束一個片段的導入之后，休息一段時間（你設定的數值就是暫停的時間，單位：毫秒），然后再開始下一個片段的導入，這樣服務器就不會太累了。

6、直接把 .sql 格式文件交給 BigDump

在本次演示中，我們先將 zip 格式的備份包上傳到服務器上，然后又將它解壓成 .sql 格式的文件，再通過 BigDump 來導入。為什么不直接用 BigDump 來導入壓縮格式的備份文件？

沒錯，BigDump 具有導入壓縮格式 SQL 備份文件（zip/gzip）的能力，但是在處理壓縮文件時，它需要先在臨時目錄中將其解壓，再讀取。請注意：這個解壓并不是一次性的，而是每導入一個小片段，就要將整個壓縮包重新解壓一次。因此，直接導入壓縮格式文件，反而使 bigdump.php 運行變慢。

7、我還有更奇怪的問題……

一般來說，運行 bigdump.php 導入一個 SQL 備份文件非常容易。如果你參照上述注意事項及操作過程，仍然不能順利完成數據庫備份文件的導入，那么請到BigDump 官方網站閱讀更多 FAQ，查找原因。