sql文件導入mysql出錯,sql server導入數據出錯

本文目錄一覽：

• 1、mysql數據庫導入錯誤
• 2、為什麼使用Mysql命令source導入.sql文件時總是出錯？
• 3、mysql導入sql文件失敗怎麼辦
• 4、當從mysql導出數據文件 「.sql」後，再導入時出現錯誤怎麼辦？

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本身就是有局限性的，太大的就是導入不進去，這個不能強求。

mysql導入sql文件失敗怎麼辦

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

mysql

source

test.sql;

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

source就是導入sql文件的命令

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

source

f:/test.sql;

當從mysql導出數據文件 「.sql」後，再導入時出現錯誤怎麼辦？

可以通過mysql數據同步的方法來解決這個問題，具體做法如下：

在本地建一個與數據庫同名的數據庫。

2.選擇navicat中連接服務器的數據庫，在菜單欄選擇工具–數據傳輸。

3.在彈出的的窗口中「源」部分就是你要導出的源數據庫，「目標」就是本地的數據庫，點擊左下角全選後，再點擊開始按鈕。

4.點擊確定。

5.點擊關閉。

6.再來查看一下本地數據庫，是不是數據和結構都已經導入到本地數據庫中了呢。然後再從備份中導出.sql再導入到本地數據庫中。

7.選擇備份文件提取SQL。

8.開始提取。

這樣我們就得到了備份轉儲的.sql文件，再將這個.sql文件導入到本地的數據庫中，就不再提示有錯誤了。