MySQL數(shù)據(jù)庫遷移快速導出導入大量數(shù)據(jù)
數(shù)據(jù)庫遷移是我們經??捎龅降膯栴},對于少量的數(shù)據(jù),遷移基本上不會有什么問題。生產環(huán)境中,有以下情況需要做遷移工作:
- 磁盤空間不夠。比如一些老項目,選用的機型并不一定適用于數(shù)據(jù)庫。隨著時間的推移,硬盤很有可能出現(xiàn)短缺;
- 業(yè)務出現(xiàn)瓶頸。比如項目中采用單機承擔所有的讀寫業(yè)務,業(yè)務壓力增大,不堪重負。如果 IO 壓力在可接受的范圍,會采用讀寫分離方案;
- 機器出現(xiàn)瓶頸。機器出現(xiàn)瓶頸主要在磁盤 IO 能力、內存、CPU,此時除了針對瓶頸做一些優(yōu)化以外,選擇遷移是不錯的方案;
- 項目改造。某些項目的數(shù)據(jù)庫存在跨機房的情況,可能會在不同機房中增加節(jié)點,或者把機器從一個機房遷移到另一個機房。再比如,不同業(yè)務共用同一臺服務器,為了緩解服務器壓力以及方便維護,也會做遷移。
MySQL遷移通常使用的有三種方法:
1、數(shù)據(jù)庫直接導出,拷貝文件到新服務器,在新服務器上導入。
2、使用第三方遷移工具。
3、數(shù)據(jù)文件和庫表結構文件直接拷貝到新服務器,掛載到同樣配置的MySQL服務下。
第一種方案的優(yōu)點:會重建數(shù)據(jù)文件,減少數(shù)據(jù)文件的占用空間,兼容性最好,導出導入很少發(fā)生問題,需求靈活。缺點:使用傳統(tǒng)導出導入時間占用長。
第二種方案的優(yōu)點:設置完成后傳輸無人值守,自動完成。缺點:不夠靈活,設置繁瑣,傳輸時間長,異常后很難從異常的位置繼續(xù)傳輸。
第三種方案的優(yōu)點:時間占用短,文件可斷點傳輸,操作步驟少。缺點:新舊服務器中MySQL版本及配置必須相同,可能引起未知問題。
假如數(shù)據(jù)庫遷移是因為業(yè)務瓶頸或項目改造等需要變動數(shù)據(jù)表結構的(比如分區(qū)分表),我們便只能使用第一種方法了。
使用MySQL的SELECT INTO OUTFILE 、LOAD DATA INFILE快速導出導入數(shù)據(jù)
LOAD DATA INFILE
語句從一個文本文件中以很高的速度讀入一個表中。MySQL官方文檔也說明了,該方法比一次性插入一條數(shù)據(jù)性能快20倍。
當用戶一前一后地使用SELECT ... INTO OUTFILE
和LOAD DATA INFILE
將數(shù)據(jù)從一個數(shù)據(jù)庫寫到一個文件中,然后再從文件中將它讀入數(shù)據(jù)庫中時,兩個命令的字段和行處理選項必須匹配。否則,LOAD DATA INFILE 將不能正確地解釋文件內容。
下面是一個項目的例子,MySQL由windows平臺遷移到Linux平臺,數(shù)據(jù)總量12G
Windows平臺導出數(shù)據(jù):
tables.txt是保存數(shù)據(jù)表名稱的文件,通過從文件中讀取數(shù)據(jù)表名稱,循環(huán)導出所有表:如果過程中攝及到分表,可根據(jù)分表規(guī)則修改導出的sql語句和批處理代碼,非常靈活。
@echo off & setlocal enabledelayedexpansion for /f %%i in (tables.txt) do ( set table=%%i echo "dump table -- !table! --" mysql -uroot -p12345678 codetc_old -e "SELECT * INTO OUTFILE 'F:/MySQL/Uploads/!table!.txt' FIELDS TERMINATED BY ',' FROM !table!" ) pause
Linux平臺導入數(shù)據(jù):
#!/bin/bash while read line do mysql -uroot -p12345678 codetc_new -e "LOAD DATA INFILE '/var/lib/mysql-files/$line.txt' INTO TABLE $line FIELDS TERMINATED BY ','" done < tables.txt
數(shù)據(jù)導入之前需在新機器上創(chuàng)建表結構,12G的數(shù)據(jù)導出用時3分鐘左右,導入用時4分鐘左右(執(zhí)行時間根據(jù)機器的配置會有所不同,不具有參考價值)
總結
以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,謝謝大家對腳本之家的支持。如果你想了解更多相關內容請查看下面相關鏈接
相關文章
mysql 松散的索引掃描(Loose index scan)
今天讀《High Performance MySQL》,發(fā)現(xiàn)一個“Loose index scan”,之前完全沒有聽說過。網上查了些資料,這個叫松散的索引掃描(Loose index scan)2016-05-05實現(xiàn)MySQL數(shù)據(jù)庫鎖的兩種方式
今天我們就來聊一聊數(shù)據(jù)庫的鎖,實現(xiàn)數(shù)據(jù)庫鎖的兩種方式,一個是實現(xiàn)樂觀鎖的方式,一個是實現(xiàn)悲觀鎖的實現(xiàn)方式,文中的代碼示例介紹的非常詳細,需要的朋友可以參考下2023-06-06MYSQL必知必會讀書筆記第四章之檢索數(shù)據(jù)
MySQL是一種開放源代碼的關系型數(shù)據(jù)庫管理系統(tǒng)(RDBMS)。接下來通過本文給大家介紹MYSQL必知必會讀書筆記第四章之檢索數(shù)據(jù),感興趣的朋友一起學習吧2016-05-05MySQL數(shù)據(jù)庫表的合并與分區(qū)實現(xiàn)介紹
今天我們來聊聊處理大數(shù)據(jù)時Mysql的存儲優(yōu)化。當數(shù)據(jù)達到一定量時,一般的存儲方式就無法解決高并發(fā)問題了。最直接的MySQL優(yōu)化就是分區(qū)分表,以下是我個人對分區(qū)分表的筆記2022-09-09MySQL報錯1040'Too?many?connections'的原因以及解決方案
這篇文章主要給大家介紹了關于MySQL報錯1040'Too?many?connections'的原因以及解決方案,文中通過實例代碼以及圖文介紹的非常詳細,需要的朋友可以參考下2022-07-07