mysql如何備份和還原數據庫？
備份數據庫使用mysqldump命令備份數據庫復制代碼代碼如下:#如果要將game數據庫進行備份：mysqldump-uroot-pgame>game_backup.sql#如果希望備份所有的數據庫：mysqldump-uroot-p--all-databases>all_backup.sql還原數據庫
1、使用mysql命令還原數據庫將game_backup.sql還原至game數據庫：復制代碼代碼如下:mysql-uroot-pgamegame_backup.sql
2、使用source命令還原數據庫如果數據庫過大，建議可以使用source命令復制代碼代碼如下:mysql>sourcegame_backup.sql
mysql備份問題，mysql版本5.7.2？
1、妳用mysqlpump壓縮備份lz4的後綴名不應該是sql，妳要.lz4才行。
mysqlpump--compress-output=LZ4>dump.lz4
lz4_decompressdump.lz4dump.txt
2、mysqlpump和mysqldump壹樣，屬於邏輯備份，備份以SQL形式的文本保存。
3、這個沒啥好建議，妳數據庫太大了，本來還想說用XtraBackup工具，但是這個只支持linux系統。
MySQL中,備份數據庫的命令是？
使用mysqldump工具進行備份：
1）備份所有數據庫：$mysqldump-uroot-p--all-database>all.sql（2）備份數據庫test$mysqldump-uroot-ptest>test.sql（3）備份數據庫test下的表emp$mysqldump-uroot-ptestemp>emp.sql（4）備份數據庫test下的表emp和dept$mysqldump-uroot-ptestempdept>emp_dept.sql
Mysql實時備份實現方法？
數據備份是數據容災的最後壹道防線，即便有著兩地三中心的架構，備份也依然重要。如果備份出問題，備份時影響了交易業務，備份數據無法恢復，這些也是企業難以承受的。所以選擇合適的備份工具尤為重要。
每個企業級數據庫都會有配套的備份工具，MEB(MySQLEnterpriseBackup)就是MySQL企業版中非常重要的工具之壹，是為企業級客戶提供的數據備份方案。
Xtrabackup壹直作為MEB開源版備胎而存在，從MySQL8.0開始情況可能會變得有所不同。
在MySQL8.0的BackupLock、RedoLogArchiving、PageTracking等新特性的加持下，MEB備份/恢復體驗會更好，目前xtrabackup還不支持這些特性。
MySQL企業版還有哪些功能？
特性1：BackupLock
8.0之前使用xtrabackup或MEB做物理備份，為了保證備份時InnoDB引擎表與其他引擎數據文件、及binlog日誌的壹致性會上全局讀鎖，再拷貝非InnoDB文件，這期間MySQL會變成只讀，數據無法寫入。表數量越多，可能加上時間越長，如果使用的xtrabackup不小心沒加rsync參數，逐個拷貝frm文件，鎖定時間會更長，對業務影響較大。
我曾遇到過部署在虛擬機的實例有12000多張表，當時使用的xtrabackup，備份腳本中沒加rsync參數，結果鎖了十幾分鐘，而MEB就沒有這樣的問題。
MySQL8.0支持輕量級備份鎖LOCKINSTANCEFORBACKUP，數據字典也重構了由InnoDB存儲。若不創建非InnoDB表，MEB默認使用備份鎖獲取binlog日誌壹致性位置，並阻止DDL操作，但不影響DML操作。
只有InnoDB表，僅上備份鎖
若有非InnoDB表，上全局鎖
特性2：RedoLogArchiving
MEB能做到在線熱備，備份時不影響數據庫讀寫，這是利用了InnoDB事務日誌，在備份期間持續監視redolog的變化，讀取增量變化，寫入到ibbackup_logfile，也就不需要上鎖來保障備份壹致性。(對非InnoDB的文件需要上讀鎖拷貝)
如果備份期間數據庫寫入負載特別大，而寫入ibbackup_logfile速度較慢，redologsize也不大，很可能會出現ibbackup_logfile的寫入速度跟不上redolog記錄生成速度，redolog空間不夠時需要覆寫日誌文件，那麽來不及寫入ibbackup_logfile的記錄會丟失，導致備份失敗。
MEB4.1對此做了優化，將redolog處理線程拆分成多線程分工合作，提高處理redolog的效率，降低了redolog覆寫造成備份失敗的概率，但redolog新增速度和ibbackup_logfile寫入速度懸殊太大，問題依然會發生。
MySQL8.0.17支持了redologarchiving徹底解決了此問題，備份前設置innodb_redo_log_archive_dirs，指定redolog歸檔目錄。MEB備份時自動開啟日誌歸檔，當checkpoint時會將舊記錄歸檔到此目錄，後續從歸檔文件中讀取redo日誌記錄，避免了覆寫可能導致的redo記錄丟失。
註意：innodb_redo_log_archive_dirs不能在數據目錄下，目錄權限要求是700
特性3：PageTracking
PageTracking是為優化增量備份效率，減少不必要的數據頁掃描。
增量備份當前有3種掃描模式：
page-track：利用LSN精確跟蹤上次備份之後被修改頁面，僅復制這些頁面，效率最快。
optimistic：掃描上次備份之後被修改的InnoDB數據文件中，找出並拷貝修改的頁面。依賴系統時間，使用存在限制。
full-scan：掃描所有InnoDB數據文件，找出並拷貝自上次備份之後修改的頁面，效率最慢
1、利用page-track增量備份，需先安裝備份組件
2、在全備前開啟page-track
3、全備之後，做增量備份時指定若滿足pagetracking條件，默認會使用page-track模式，否則會使用full-scan模式，也可以指定--incremental=page-track。
incremental-base有3種選擇
last_backup：基於前壹次備份做增備，前壹次備份可能是增備，也可能是全備。這種方式全備之間可能會有多個增備，每次增量可能比較小，但恢復時需要逐個合並。
last_full_backup：基於前壹次全備做增備。這種方式增備會越往後體積可能越大，但恢復時只需要合並最後壹次增量備份。
dir：基於前壹次的備份目錄，前壹次備份可能是增備，也可能是全備。
測試對比full-scan和page-track，在變更頁小於總體50%的情況下，備份效率至少能有1倍的速度提升。
page-track模式磁盤讀寫均衡，說明讀寫的都是修改頁面。
full-scan模式磁盤讀寫差別很大，說明讀了很多未修改的頁面。