mysql導入sql文件不成功（mysql無法導入文件）

本文目錄一覽：

• 1、mysql導入sql文件失敗怎麼辦
• 2、mysql導入sql文件報1064失敗
• 3、mysql導入資料庫文件出錯，求高手指點
• 4、為什麼使用Mysql命令source導入.sql文件時總是出錯？

mysql導入sql文件失敗怎麼辦

進入mysql後使用如下命令導入sql腳本文件：

mysql

source

test.sql;

其實test.sql就是你要導入的sql文件

source就是導入sql文件的命令

比如你在f盤有個test.sql文件，導入命令如下：

source

f:/test.sql;

mysql導入sql文件報1064失敗

是否有創建資料庫

查詢導入的格式

文件是否被修改

可以在源系統上把結構選擇導出來,然後先導入結構看是否有問題,如沒有問題再重新導一次

可以通過navicat工具去操作

mysql導入資料庫文件出錯，求高手指點

如果從庫上表 t 數據與主庫不一致，導致複製錯誤，整個庫的數據量很大，重做從庫很慢，如何單獨恢復這張表的數據？通常認為是不能修復單表數據的，因為涉及到各表狀態不一致的問題。下面就列舉備份單表恢復到從庫會面臨的問題以及解決辦法：

場景 1

如果複製報錯後，沒有使用跳過錯誤、複製過濾等方法修復主從複製。主庫數據一直在更新，從庫數據停滯在報錯狀態（假設 GTID 為 aaaa:1-100）。

修復步驟：

在主庫上備份表 t （假設備份快照 GTID 為 aaaa:1-10000）；

恢復到從庫；

啟動複製。

這裡的問題是複製起始位點是 aaaa:101，從庫上表 t 的數據狀態是領先其他表的。aaaa:101-10000 這些事務中只要有修改表 t 數據的事務，就會導致複製報錯 ，比如主鍵衝突、記錄不存在（而 aaaa:101 這個之前複製報錯的事務必定是修改表 t 的事務）

解決辦法：啟動複製時跳過 aaaa:101-10000 這些事務中修改表 t 的事務。

正確的修復步驟：

1. 在主庫上備份表 t （假設備份快照 GTID 為 aaaa:1-10000），恢復到從庫；

2. 設置複製過濾，過濾表 t：

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = (‘db_name.t’);

3. 啟動複製，回放到 aaaa:10000 時停止複製（此時從庫上所有表的數據都在同一狀態，是一致的）;

START SLAVE UNTIL SQL_AFTER_GTIDS = ‘aaaa:10000’;

4. 刪除複製過濾，正常啟動複製。

注意事項：這裡要用 mysqldump –single-transaction –master-data=2，記錄備份快照對應的 GTID

場景 2

如果複製報錯後，使用跳過錯誤、複製過濾等辦法修復了主從複製。主、從庫數據一直在更新。

修復步驟：

在主庫上備份表 t （假設備份快照 GTID為 aaaa:1-10000）；

停止從庫複製，GTID為 aaaa:1-20000；

恢復表 t 到從庫；

啟動複製。

這裡的問題是複製起始位點是 aaaa:20001，aaaa:10000-20000 這些事務將不會在從庫上回放，如果這裡面有修改表 t 數據的事務，從庫上將丟失這部分數據。

解決辦法：從備份開始到啟動複製，鎖定表 t，保證 aaaa:10000-20000 中沒有修改表 t 的事務。

正確修復步驟：

對錶 t 加讀鎖；

在主庫上備份表 t；

停止從庫複製，恢復表 t；

啟動複製；

解鎖表 t。

如果是大表，這裡可以用可傳輸表空間方式備份、恢復表，減少鎖表時間。

為什麼使用Mysql命令source導入.sql文件時總是出錯？

換工具導入唄，navcat或者sqlyog

命令導入就只有這樣的方法，source

地址,語法是沒有錯誤的，你導入失敗可能的原因有很多啊，比如說sql中沒有創建資料庫的語句，或者由於cmd命令行的限制產生的其他錯誤啊，CMD本身就是有局限性的，太大的就是導入不進去，這個不能強求。