mysqldump 是 Mysql 自帶的邏輯備份工具。其備份原理是經過協議鏈接到 Mysql 數據庫,將須要備份的數據查詢出來轉換成對應的 insert 語句。當須要還原這些數據時,只要執行這些 insert 語句,便可將對應的數據還原。 mysql
經常使用命令:sql
導出全部數據庫數據庫
mysqldump -uroot -p123456 --all-databases >/tmp/all.sql
導出指定數據庫分佈式
mysqldump -uroot -p123456 --databases db >/tmp/db.sql
導出指定表工具
mysqldump -uroot -p123456 --databases db --tables a >/tmp/a.sql
根據條件導出數據3d
mysqldump -uroot -p123456 --databases db --tables a --where='id=1' >/tmp/a.sql
只導出表結構code
mysqldump -uroot -p123456 --no-data --databases db >/tmp/db.sql
source 命令能夠將導出的 sql 文件導入進指定數據庫。blog
操做步驟:索引
use 數據庫;it
soucre 已導出的 sql 文件。
1. 數據庫A歷史數據遷移到 hdfs(一種分佈式文件系統)上進行歸檔;
2. 刪除數據庫A已歸檔的表,使用 drop 命令;
3. 數據庫A上新建表,用於數據庫B遷移;
4. 數據庫B中除未完成單外都遷移至數據庫A;
5. 腳本進行刪除數據庫B上已遷移數據。
在 Innodb 存儲引擎中,innodb_file_per_table 參數是用來控制表數據的存儲方式的。
當參數爲 OFF 的時候,全部數據都存放於默認路徑下名爲 ibdata* 的共享表空間裏,即將數據庫全部的表數據及索引文件存放到一個文件中。在刪除數據表的時候,ibdata* 文件不會自動收縮。
當參數爲 ON 的時候,每個表都將存儲在一個以 .ibd 爲後綴的文件中。這樣每一個表都有了本身獨立的表空間,經過 drop table 命令就能夠將表空間進行回收。
從 Mysql 5.6.6 版本開始,innodb_file_per_table 默認爲 ON 狀態。
經過 show variables like '%per_table%' 命令,能夠查看 innodb_file_per_table 參數的當前狀態:
若是想修改參數的狀態,可經過 SET GLOBAL 動態地修改成 ON 或 OFF,也能夠在 my.cnf 中作永久性修改。須要注意的是,在 my.cnf 中修改後生效的話須要重啓 mysqld 服務。
疑問:若是以前參數爲 OFF 狀態,設置爲 ON 狀態後,表空間如何分配?
答案是僅對後續操做生效。
什麼意思呢?修改前的數據還維持原狀,也就是說以前的數據繼續存放於 ibdata* 文件中,修改後的使用獨立表空間。
因此建議在開始就將該參數設置爲 ON 狀態。
在這以前要先介紹下 Innodb 存儲數據所用的 B+ 樹結構,畫個圖你理解下:
在圖中,P 表明一頁數據,R 表明一行數據。
假設咱們要刪掉 R2 這條記錄,InnoDB 引擎只會將其標記爲刪除狀態,並不會真正把這行數據所佔的空間釋放掉,也就是說這個坑位還留着。若是後續所插入的數據在 R1 與 R3 之間的話,這個空間是能夠被使用上的。
假設咱們剛好刪除了 R一、R二、R3 這三條記錄,也就是說 P1 這一頁的數據都被刪掉了,那麼 P1 所在的空間都會被標記爲可複用。若是插入的數據須要使用新頁的話,P1 的坑位就能夠被利用起來了。
那麼你可能會問了,我插入的數據剛好巧妙的避開了這些位置呢。那我還能說啥,騷唄。這樣會形成不少空間被浪費,若是刪除大量的數據的話,被浪費的空間也會是巨大的。
optimize table 的本質是 ALTER TABLE xxx ENGINE = InnoDB;
在5.5版本以前,重建表的過程是這樣的:
而後用臨時文件替換舊錶,這樣便實現了表的重建。
一、控制遷移速度,防止主從延遲致使線上故障;
二、建立大表時,使用下面的建表語句可節省 50% 左右的空間:
ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8
三、使用 optimize table 壓縮表時,須要留夠必定的空間。
做者:你們好,我是萊烏,BAT搬磚工一枚。從小公司進入大廠,一路走來收穫良多,想將這些經驗分享給有須要的人,所以建立了公衆號「IT界農民工」。定時更新,但願能幫助到你。