Navicat 導入 MySQL 資料庫常見問題與解決實錄

前言：為什麼「執行成功」卻查不到資料表？

許多開發者在使用 Navicat 這類圖形化工具匯入 SQL 檔案時，都曾遇過這種令人困惑的情況：介面明明顯示 「queries successfully」 或類似的成功訊息，但刷新資料庫列表後，預期的資料表卻空空如也。這篇文章記錄一次真實的排查過程，希望能為遇到相同困境的人提供一個新的思路。

問題複現：用「執行 SQL 檔案」匯入失敗

嘗試將先前備份的 easy.sql 匯入新建立的資料庫。操作步驟如下：

1. 在 Navicat 中選取目標資料庫。
2. 右鍵選擇「執行 SQL 檔案」，載入 easy.sql。
3. 執行過程無報錯，日誌輸出「queries successfully」。
4. 展開資料庫的「資料表」節點 —— 空無一物。

多次重試、檢查 SQL 檔案內容（確認包含 CREATE TABLE 與 INSERT 語句）均無效，甚至懷疑是權限或編碼問題，但方向皆不對。

意外發現：重建同名資料庫竟然自動恢復？

在無奈之下，決定採取較激進的手段：

1. 刪除剛建立的目標資料庫，甚至連同 MySQL 服務實例一併移除（視具體環境而定）。
2. 重新安裝/啟動 MySQL 服務。
3. 建立一個 與原 SQL 檔案中指定資料庫名稱完全相同 的新資料庫。
4. 重啟 MySQL 服務。

神奇的一幕發生了：不用再手動執行任何 SQL 檔案，資料表結構與資料竟然完整地出現在新資料庫中！

原因分析與經驗總結

這極大概率是因為 easy.sql 檔案本身包含了 CREATE DATABASE IF NOT EXISTS `db_name`; 以及 USE `db_name`; 語句，且該 SQL 檔案原本是透過 mysqldump 導出的完整備份。

• Navicat「執行 SQL 檔案」的陷阱： 當你在已選取某資料庫的連線下執行 SQL 時，工具可能會忽略腳本中的 CREATE DATABASE 與 USE 指令，導致語句在錯隱含的 Schema 下執行，或因權限/事務問題靜默失敗，卻仍回報成功。
• 資料庫目錄機制： MySQL 的資料目錄下，每個資料庫對應一個資料夾。當服務啟動時，會自動掃描資料目錄下的資料夾並識別為資料庫。若 SQL 檔案曾被執行過（即使看似失敗），其物理檔案可能已寫入磁碟；重建同名資料庫時，服務直接掛載了現有的資料目錄。

最佳實踐建議

1. 優先使用「還原」功能而非「執行 SQL 檔案」： 在 Navicat 中右鍵資料庫選擇「還原」，專為 mysqldump 格式備份設計，能正確處理資料庫建立、切換、鎖表等邏輯。
2. 命令列匯入最可靠： mysql -u root -p db_name < easy.sql 避免 GUI 工具的解析差異。
3. 檢查 SQL 檔案頭部： 確認是否包含 CREATE DATABASE 與 USE，決定是先建庫再匯入，還是直接匯入。
4. 關注事務與自動提交： 大量資料匯入時，確認工具是否開啟了自動提交，或在腳本中顯式加入 COMMIT;。

結語

工具雖好，懂原理才不踩坑。下次遇到「成功卻無資料」，不妨先看看 SQL 裡有沒有 CREATE DATABASE，試試「還原」或命令列，甚至像文中這樣「重建同名庫」這招非常規手段 —— 有時候，MySQL 已經在背後幫你把活幹了。