MySQL 導入大 SQL 文件超時/報錯終極解決方案

MySQL 導入大 SQL 文件超時/報錯終極解決方案

現場導入幾百 MB 甚至 GB 級 SQL 文件時，常遇到 MySQL server has gone away、Lost connection to MySQL server 或導入極其緩慢。本文提供一組「屢試不爽」的全局變量調整組合拳，針對網絡傳輸緩衝、超時閾值、封包大小三大核心痛點一次性解決。

核心調優指令（在 MySQL 客戶端執行）

SET GLOBAL max_allowed_packet = 100000000;  -- 100MB，最大通信封包
SET GLOBAL net_buffer_length = 100000;      -- 100KB，TCP/Socket 通信緩衝區
SET GLOBAL interactive_timeout = 28800000;  -- 8小時，交互式連接空閒超時
SET GLOBAL wait_timeout = 28800000;         -- 8小時，非交互式連接空閒超時

參數深度解析

持久化配置（寫入 my.cnf）

[mysqld]
max_allowed_packet = 100M
net_buffer_length = 100K
interactive_timeout = 28800000
wait_timeout = 28800000

修改後 systemctl restart mysqld 生效，避免重啟失效。

輔助最佳實踐

• 源端導出優化：mysqldump --single-transaction --quick --max_allowed_packet=100M db > dump.sql
• 分片導入：使用 sed/awk 或 pt-fifo-split 將大文件切分為 50MB 片段，併發導入
• 禁用索引/外鍵：導入前 SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0;，導入後恢復
• 使用源命令而非管道：mysql> source /path/dump.sql 比 mysql < dump.sql 更穩定（客戶端側緩衝）

常見誤區

1. 只調 max_allowed_packet 忽略 net_buffer_length，導致大語句分片傳輸仍超時
2. 超時值設得過大（如 31536000 秒）引發連接泄漏風險，建議 8-24 小時
3. 未同步調整客戶端 --max-allowed-packet 參數