實戰解決 MySQL 中文亂碼：mysqldump 導出與 phpMyAdmin 導入完整避坑指南

將本地 GBK 編碼 MySQL 資料庫遷移至僅提供 phpMyAdmin 的虛擬主機，歷經 Navicat 導出亂碼、mysqldump 參數調試、鎖表權限不足、phpMyAdmin 導入編碼錯誤等多重坑點，最終完整落地。記錄全流程供參考。

問題場景

• 本地：Windows + Navicat + GBK 編碼資料庫
• 目標：Linux 虛擬主機 + 僅 phpMyAdmin 管理 + 無獨立權限

步驟 1：正確導出 SQL 檔案

❌ Navicat 「轉儲 SQL」直接導出 → 中文全亂碼

單表導出正常，但 82 張表逐個操作不現實。

❌ mysqldump 預設導出 → 仍亂碼

mysqldump -uroot -p123 dbname > dump.sql

✅ 指定字符集導出（關鍵）

mysqldump -uroot -p123 --default-character-set=gbk dbname > dump_gbk.sql

打開檔案確認中文正常顯示（ANSI/GBK 編碼）。

步驟 2：解決導入鎖表權限錯誤

phpMyAdmin 導入報錯：LOCK TABLES ... Access denied，虛擬主機無 LOCK TABLES 權限。

❌ --skip-lock-tables 無效

該參數僅影響備份時一致性，不控制輸出是否包含 LOCK 陳述句。

✅ 正確參數：--add-locks=false

mysqldump -uroot -p123 --default-character-set=gbk --add-locks=false dbname > dump_nolock.sql

輸出檔不再包含 LOCK TABLES/UNLOCK TABLES。

步驟 3：phpMyAdmin 導入編碼設置（三處必改）

1. MySQL 連線校對：選 gbk_chinese_ci
2. 介面語言：切換為中文（簡體）
3. 匯入檔案字符集：選 gbk（預設 utf-8 會導致亂碼）

圖 1：Navicat 對整個資料庫轉 SQL

關鍵避坑總結

編碼遷移核心原則：導出端指定源編碼、導入端指定目標編碼、中間檔案編碼一致。虛擬主機受限環境下，mysqldump + phpMyAdmin 仍可平穩完成 GBK→GBK 遷移。