1樓：愛可生雲資料庫
資料備份是資料容災的最後一道防線，即便有著兩地三中心的架構，備份也依然重要。如果備份出問題，備份時影響了交易業務，備份資料無法恢復，這些也是企業難以承受的。所以選擇合適的備份工具尤為重要。
每個企業級資料庫都會有配套的備份工具，meb(mysql enterprise backup)就是mysql企業版中非常重要的工具之一，是為企業級客戶提供的資料備份方案。
xtrabackup一直作為meb 開源版備胎而存在，從mysql 8.0開始情況可能會變得有所不同。
在 mysql 8.0的backup lock、redo log archiving、page tracking等新特性的加持下，meb備份/恢復體驗會更好，目前xtrabackup還不支援這些特性。
mysql 企業版還有哪些功能？
特性1：backup lock
8.0之前使用xtrabackup或meb做物理備份，為了保證備份時innodb引擎表與其他引擎資料檔案、及binlog日誌的一致性會上全域性讀鎖，再拷貝非innodb檔案，這期間mysql會變成唯讀，資料無法寫入。表數量越多，可能加上時間越長，如果使用的xtrabackup 不小心沒加rsync引數，逐個拷貝frm檔案，鎖定時間會更長，對業務影響較大。
我曾遇到過部署在虛擬機器的例項有12000多張表，當時使用的xtrabackup，備份指令碼中沒加rsync引數，結果鎖了十幾分鐘，而meb就沒有這樣的問題。
mysql 8.0支援輕量級備份鎖 lock instance for backup，資料字典也重構了由innodb儲存。若不建立非innodb表，meb預設使用備份鎖獲取binlog日誌一致性位置，並阻止ddl操作，但不影響dml操作。
只有innodb表，僅上備份鎖
請點選輸入**描述
若有非innodb表，上全域性鎖
請點選輸入**描述
特性2：redo log archiving
如果備份期間資料庫寫入負載特別大，而寫入ibbackup_logfile速度較慢，redo log size也不大，很可能會出現ibbackup_logfile的寫入速度跟不上redo log記錄生成速度，redo log 空間不夠時需要覆寫日誌檔案，那麼來不及寫入ibbackup_logfile的記錄會丟失，導致備份失敗。
meb 4.1對此做了優化，將redo log處理執行緒拆分成多執行緒分工合作，提高處理redo log的效率，降低了redo log覆寫造成備份失敗的概率，但redo log新增速度和ibbackup_logfile寫入速度懸殊太大，問題依然會發生。
mysql 8.0.17支援了redo log archiving 徹底解決了此問題，備份前設定innodb_redo_log_archive_dirs，指定redo log歸檔目錄。
meb備份時自動開啟日誌歸檔，當checkpoint時會將舊記錄歸檔到此目錄，後續從歸檔檔案中讀取redo日誌記錄，避免了覆寫可能導致的redo記錄丟失。
請點選輸入**描述
注意：innodb_redo_log_archive_dirs 不能在資料目錄下，目錄許可權要求是700
特性3：page tracking
page tracking 是為優化增量備份效率，減少不必要的資料頁掃瞄。
增量備份當前有3種掃瞄模式：
page-track：利用lsn精確跟蹤上次備份之後被修改頁面，僅複製這些頁面，效率最快。
optimistic：掃瞄上次備份之後被修改的innodb 資料檔案中，找出並拷貝修改的頁面。依賴系統時間，使用存在限制。
full-scan：掃瞄所有innodb資料檔案，找出並拷貝自上次備份之後修改的頁面，效率最慢
1、利用page-track增量備份，需先安裝備份元件
mysql> install component "file://component_mysqlbackup";
2、在全備前開啟page-track
select mysqlbackup_page_track_set(true);
3、全備之後，做增量備份時指定若滿足page tracking條件，缺省會使用page-track模式，否則會使用full-scan模式，也可以指定--incremental=page-track。
mysqlbackup --incremental-backup-dir=backup_incr --trace=3 --incremental=page-track --incremental-base=history:last_full_backup backup
incremental-base有3種選擇
last_backup：基於前一次備份做增備，前一次備份可能是增備，也可能是全備。這種方式全備之間可能會有多個增備，每次增量可能比較小，但恢復時需要逐個合併。
last_full_backup：基於前一次全備做增備。這種方式增備會越往後體積可能越大，但恢復時只需要合併最後一次增量備份。
dir：基於前一次的備份目錄，前一次備份可能是增備，也可能是全備。
測試對比full-scan 和page-track ，在變更頁小於總體50%的情況下 ，備份效率至少能有1倍的速度提公升。
page-track 模式 磁碟讀寫均衡，說明讀寫的都是修改頁面。
請點選輸入**描述
full-scan模式 磁碟讀寫差別很大，說明讀了很多未修改的頁面。
請點選輸入**描述
如何備份和還原mysql資料庫裡的資料？
2樓：爬來爬去
找到伺服器上 mysql的資料庫存放路徑下面的資料庫名檔案，拷貝過去放到新伺服器的對應路徑下就可以了
比如你要備份test的資料庫 ，就到你的mysql安裝目錄d:\mysql\data下面把test這個資料夾整個複製走就可以了
3樓：
你能直接登陸伺服器並能取伺服器本地的檔案嗎?
如果能,那就登陸上伺服器,在上面執行mysqldump工具備份即可.
如果不能登陸，那你就用第3方工具吧,如:sqlyog enterprise
備份:用sqlyog enterprise登陸上去,選用你要備份的資料庫--->右鍵選"backup database as sql dump",然後按提示設定並選好儲存結果的路徑即可.
還原:用sqlyog enterprise登陸上去,先建立乙個庫,然後選用你要恢復的資料庫--->右鍵選"restore from sql dump",然後按提示設定並選好對應路徑下的檔案即可.
4樓：愛可生雲資料庫
備份資料庫的工具需要注意，僅供參考。
資料備份是資料容災的最後一道防線，即便有著兩地三中心的架構，備份也依然重要。如果備份出問題，備份時影響了交易業務，備份資料無法恢復，這些也是企業難以承受的。所以選擇合適的備份工具尤為重要。
每個企業級資料庫都會有配套的備份工具，meb(mysql enterprise backup)就是mysql企業版中非常重要的工具之一，是為企業級客戶提供的資料備份方案。
xtrabackup一直作為meb 開源版備胎而存在，從mysql 8.0開始情況可能會變得有所不同。
在 mysql 8.0的backup lock、redo log archiving、page tracking等新特性的加持下，meb備份/恢復體驗會更好，目前xtrabackup還不支援這些特性。
mysql 企業版還有哪些功能？
特性1：backup lock
8.0之前使用xtrabackup或meb做物理備份，為了保證備份時innodb引擎表與其他引擎資料檔案、及binlog日誌的一致性會上全域性讀鎖，再拷貝非innodb檔案，這期間mysql會變成唯讀，資料無法寫入。表數量越多，可能加上時間越長，如果使用的xtrabackup 不小心沒加rsync引數，逐個拷貝frm檔案，鎖定時間會更長，對業務影響較大。
我曾遇到過部署在虛擬機器的例項有12000多張表，當時使用的xtrabackup，備份指令碼中沒加rsync引數，結果鎖了十幾分鐘，而meb就沒有這樣的問題。
mysql 8.0支援輕量級備份鎖 lock instance for backup，資料字典也重構了由innodb儲存。若不建立非innodb表，meb預設使用備份鎖獲取binlog日誌一致性位置，並阻止ddl操作，但不影響dml操作。
只有innodb表，僅上備份鎖
請點選輸入**描述
若有非innodb表，上全域性鎖
請點選輸入**描述
特性2：redo log archiving
如果備份期間資料庫寫入負載特別大，而寫入ibbackup_logfile速度較慢，redo log size也不大，很可能會出現ibbackup_logfile的寫入速度跟不上redo log記錄生成速度，redo log 空間不夠時需要覆寫日誌檔案，那麼來不及寫入ibbackup_logfile的記錄會丟失，導致備份失敗。
meb 4.1對此做了優化，將redo log處理執行緒拆分成多執行緒分工合作，提高處理redo log的效率，降低了redo log覆寫造成備份失敗的概率，但redo log新增速度和ibbackup_logfile寫入速度懸殊太大，問題依然會發生。
mysql 8.0.17支援了redo log archiving 徹底解決了此問題，備份前設定innodb_redo_log_archive_dirs，指定redo log歸檔目錄。
meb備份時自動開啟日誌歸檔，當checkpoint時會將舊記錄歸檔到此目錄，後續從歸檔檔案中讀取redo日誌記錄，避免了覆寫可能導致的redo記錄丟失。
請點選輸入**描述
注意：innodb_redo_log_archive_dirs 不能在資料目錄下，目錄許可權要求是700
特性3：page tracking
page tracking 是為優化增量備份效率，減少不必要的資料頁掃瞄。
增量備份當前有3種掃瞄模式：
page-track：利用lsn精確跟蹤上次備份之後被修改頁面，僅複製這些頁面，效率最快。
optimistic：掃瞄上次備份之後被修改的innodb 資料檔案中，找出並拷貝修改的頁面。依賴系統時間，使用存在限制。
full-scan：掃瞄所有innodb資料檔案，找出並拷貝自上次備份之後修改的頁面，效率最慢
1、利用page-track增量備份，需先安裝備份元件
mysql> install component "file://component_mysqlbackup";
2、在全備前開啟page-track
select mysqlbackup_page_track_set(true);
3、全備之後，做增量備份時指定若滿足page tracking條件，缺省會使用page-track模式，否則會使用full-scan模式，也可以指定--incremental=page-track。
mysqlbackup --incremental-backup-dir=backup_incr --trace=3 --incremental=page-track --incremental-base=history:last_full_backup backup
incremental-base有3種選擇
last_backup：基於前一次備份做增備，前一次備份可能是增備，也可能是全備。這種方式全備之間可能會有多個增備，每次增量可能比較小，但恢復時需要逐個合併。
last_full_backup：基於前一次全備做增備。這種方式增備會越往後體積可能越大，但恢復時只需要合併最後一次增量備份。
dir：基於前一次的備份目錄，前一次備份可能是增備，也可能是全備。
測試對比full-scan 和page-track ，在變更頁小於總體50%的情況下 ，備份效率至少能有1倍的速度提公升。
page-track 模式 磁碟讀寫均衡，說明讀寫的都是修改頁面。
請點選輸入**描述
full-scan模式 磁碟讀寫差別很大，說明讀了很多未修改的頁面。
請點選輸入**描述
mysql如何建立資料庫的檢視設計
在 sql 中，視來圖是基於 sql 語句的結果自集的視覺化的表。檢視包含行和列，就像乙個真實的表。檢視中的字段就是來自乙個或多個資料庫中的真實的表中的字段。我們可以向檢視新增 sql 函式 where 以及 join 語句，我們也可以提交資料，就像這些來自於某個單一的表。例子建立檢視 create...
php連線mysql資料庫問題,mysql資料庫怎麼連線資料庫
public listpagelisttwo int currentpage,int showrows connection con null preparedstatement ps null resultset rs null arraylistresultlist new arraylist ...
連線mysql資料庫問題
1.是的了，你應該先輸入 d 2.然後才進入到d盤，然後再輸入 d wamp bin mysql mysql5.0.45 bin3.進行到這一步，已經進入到了mysql的目錄，然後連線資料庫 mysql u root p 4.到這裡，會讓你輸入資料庫密碼，如果沒有直接回車，有的話輸入。至此，命令符已...