mysql數據庫的備份與遷移（MySQL 數據庫備份）

本文目錄一覽：

• 1、mysql中備份和還原數據庫的語句什麼啊
• 2、如何對mysql備份
• 3、如何遷移MySQL數據庫
• 4、mysql數據庫備份
• 5、MySQL備份的幾種常用
• 6、mysql數據庫備份和還原

mysql中備份和還原數據庫的語句什麼啊

一、Mysql數據庫備份指令格式：

mysqldump -h主機名 -P端口 -u用戶名 -p密碼 (–database) 數據庫名 文件名.sql

註：直接cmd執行該指令即可，不需要先mysql -u root -p鏈接數據庫

1、備份MySQL數據庫的命令

mysqldump -hhostname -uusername -ppassword databasename backupfile.sql

2、備份MySQL數據庫為帶刪除表的格式，能夠讓該備份覆蓋已有數據庫而不需要手動刪除原有數據庫。

mysqldump -–add-drop-table -uusername -ppassword databasename backupfile.sql

二、數據庫還原有三種方式：source命令、mysql、gunzip命令

1、source 命令

進入mysql數據庫控制台，

mysql -u root -p

mysqluse 數據庫

然後使用source命令，後面參數為腳本文件（如這裡用到的.sql）

mysqlsource /home/work/db/bkdb.sql

2、mysql

mysql -hhostname -uusername -ppassword databasename backupfile.sql

3、gunzip

gunzip backupfile.sql.gz | mysql -uusername -ppassword databasename

如何對mysql備份

Mysql數據庫的常用備份方法是使用使用實用程序mysqldump, 其命令格式如下

# mysqldump [options] database [tables]

其參數的含義為：

options：代表mysqldump的選項，通過mysqldump –help可以查到。

database: 代表將要備份的數據庫

tables: 代表將要備份的表，如果不指定任何錶，則備份整個數據庫。

使用 mysqldump進行備份非常簡單，如果要備份數據庫” phpbb_db_backup ”,使用命令：

#mysqldump –u -p phpbb_db_backup /usr/backups/mysql/ phpbb_db_backup.2005.5.6

還可以使用gzip命令對備份文件進行壓縮：

#mysqldump phpbb_db_backup | gzip /usr/backups/mysql/ phpbb_db_backup.2005.5.6。gz

恢複數據使用命令：

#mysql –u -p phpbb_db_backup /usr/backups/mysql/phpbb_db_backup.2005

如何遷移MySQL數據庫

caching_sha2_password認證插件提供更多的密碼加密方式，並且在加密方面具有更好的表現，目前MySQL 8.0選用caching_sha2_password作為默認的認證插件，MySQL 5.7的認證插件是MySQL_native_password。如果客戶端版本過低，會造成無法識別MySQL 8.0的加密認證方式，最終導致連接問題。

MySQL存儲引擎現在負責提供自己的分區處理程序，而MySQL服務器不再提供通用分區支持，InnoDB和NDB是唯一提供MySQL 8.0支持的本地分區處理程序的存儲引擎。 如果分區表用的是別的存儲引擎，存儲引擎必須進行修改。要麼將其轉換為InnoDB或NDB，要麼刪除其分區。通過MySQLdump從5.7獲取的備份文件，在導入到8.0環境前，需要確保創建分區表語句中指定的存儲引擎必須支持分區，否則會報錯。

MySQL 8.0的默認字符集utf8mb4，可能會導致之前數據的字符集跟新建對象的字符集不一致，為了避免新舊對象字符集不一致的情況，可以在配置文件將字符集和校驗規則設置為舊版本的字符集和校驗規則。

MySQL 8.0啟動使用的lower_case_table_names值必須跟初始化時使用的一致。使用不同的設置重新啟動服務器會引入與標識符的排序和比較方式不一致的問題。

 lower_case_table_names 

要避免MySQL 8.0上的啟動失敗，MySQL配置文件中的sql_mode系統變量不能包含NO_AUTO_CREATE_USER。

從MySQL 5.7.24和MySQL 8.0.13開始，MySQLdump從存儲程序定義中刪除了NO_AUTO_CREATE_USER。必須手動修改使用早期版本的MySQLdump創建的轉儲文件，以刪除NO_AUTO_CREATE_USER。

在MySQL 8.0.11中，刪除了這些不推薦使用的兼容性SQL Mode：DB2，MAXDB，MSSQL，MySQL323，MySQL40，ORACLE，POSTGRESQL，NO_FIELD_OPTIONS，NO_KEY_OPTIONS，NO_TABLE_OPTIONS。從5.7到8.0的複製場景中，如果語句使用到廢棄的SQL Mode會導致複製異常。

在執行到MySQL 8.0.3或更高版本的in-place升級時，BACKUP_ADMIN權限自動授予具有RELOAD權限的用戶。

本文對MySQL 5.7到MySQL 8.0的升級過程中出現部分易出現問題進行整理：升級對MySQL版本的要求、升級都做了哪些內容、數據庫升級做了哪些步驟以及注意事項，希望對大家版本升級有幫助。

mysql數據庫備份

在數據庫表丟失或損壞的情況下，備份你的數據庫是很重要的。如果發生系統崩潰，你肯定想能夠將你的表儘可能丟失最少的數據恢復到崩潰發生時的狀態。有時，正是MySQL管理員造成破壞。管理員已經知道表以破壞，用諸如vi或Emacs等編輯器試圖直接編輯它們，這對錶絕對不是件好事！

備份數據庫兩個主要方法是用mysqldump程序或直接拷貝數據庫文件（如用cp、cpio或tar等）。每種方法都有其優缺點：

• mysqldump與MySQL服務器協同操作。直接拷貝方法在服務器外部進行，並且你必須採取措施保證沒有客戶正在修改你將拷貝的表。如果你想用文件系統備份來備份數據庫，也會發生同樣的問題：如果數據庫表在文件系統備份過程中被修改，進入備份的表文件主語不一致的狀態，而對以後的恢復表將失去意義。文件系統備份與直接拷貝文件的區別是對後者你完全控制了備份過程，這樣你能採取措施確保服務器讓表不受干擾。

• mysqldump比直接拷貝要慢些。

• mysqldump生成能夠移植到其它機器的文本文件，甚至那些有不同硬件結構的機器上。直接拷貝文件不能移植到其它機器上，除非你正在拷貝的表使用MyISAM存儲格式。ISAM表只能在相似的硬件結構的機器上拷貝。在MySQL 3.23中引入的MyISAM表存儲格式解決了該問題，因為該格式是機器無關的，所以直接拷貝文件可以移植到具有不同硬件結構的機器上。只要滿足兩個條件：另一台機器必須也運行MySQL 3.23或以後版本，而且文件必須以MyISAM格式表示，而不是ISAM格式。

不管你使用哪種備份方法，如果你需要恢複數據庫，有幾個原則應該遵守，以確保最好的結果：

• 定期實施備份。建立一個計劃並嚴格遵守。

• 讓服務器執行更新日誌。當你在崩潰後需要恢複數據時，更新日誌將幫助你。在你用備份文件恢複數據到備份時的狀態後，你可以通過運行更新日誌中的查詢再次運用備份後面的修改，這將數據庫中的表恢復到崩潰發生時的狀態。

• 以文件系統備份的術語講，數據庫備份文件代表完全傾倒（full dump），而更新日誌代表漸進傾倒（incremental dump）。

• 使用一種統一的和易理解的備份文件命名機制。象backup1、buckup2等不是特別有意義。當實施你的恢復時，你將浪費時間找出文件里是什麼東西。你可能發覺用數據庫名和日期構成備份文件名會很有用。例如：

• %mysqldump samp_db /usr/archives/mysql/samp_db.1999-10-02

• %mysqldump menagerie /usr/archives/mysql/menagerie.1999-10-02

• 你可能想在生成備份後壓縮它們。備份一般都很大！你也需要讓你的備份文件有過期期限以避免它們填滿你的磁盤，就象你讓你的日誌文件過期那樣。

• 用文件系統備份備份你的備份文件。如果遇上了一個徹底崩潰，不僅清除了你的數據目錄，也清除了包含你的數據庫備份的磁盤驅動器，你將真正遇上了麻煩。也要備份你的更新日誌。

• 將你的備份文件放在不同於用於你的數據庫的文件系統上。這將降低由於生成備份而填滿包含數據目錄的文件系統的可能性。

用於創建備份的技術同樣對拷貝數據庫到另一台機器有用。最常見地，一個數據庫被轉移到了運行在另一台主機上的服務器，但是你也可以將數據轉移到同一台主機上的另一個服務器。

1 使用mysqldump備份和拷貝數據庫

當你使用mysqldumo程序產生數據庫備份文件時，缺省地，文件內容包含創建正在傾倒的表的CREATE語句和包含表中行數據的INSERT語句。換句話說，mysqldump產生的輸出可在以後用作mysql的輸入來重建數據庫。

你可以將整個數據庫傾倒進一個單獨的文本文件中，如下：

%mysqldump samp_db /usr/archives/mysql/samp_db.1999-10-02

輸出文件的開頭看起來象這樣：

# MySQL Dump 6.0# # Host: localhost Database: samp_db#—————————————# Server version 3.23.2-alpha-log## Table structure for table ‘absence’#CREATE TABLE absence( student_id int(10) unsigned DEFAULT ‘0’ NOT NULL, date date DEFAULT ‘0000-00-00’ NOT NULL, PRIMARY KEY (student_id,date));## Dumping data for table ‘absence’#INSERT INTO absence VALUES (3,’1999-09-03′);INSERT INTO absence VALUES (5,’1999-09-03′);INSERT INTO absence VALUES (10,’1999-09-08’);……

文件剩下的部分有更多的INSERT和CREATE TABLE語句組成。

如果你想壓縮備份，使用類似如下的命令：

%mysqldump samp_db | gzip /usr/archives/mysql/samp_db.1999-10-02.gz

如果你要一個龐大的數據庫，輸出文件也將很龐大，可能難於管理。如果你願意，你可以在mysqldump命令行的數據庫名後列出單獨的表名來傾到它們的內容，這將傾倒文件分成較小、更易於管理的文件。下例顯示如何將samp_db數據庫的一些表傾到進分開的文件中：

%mysqldump samp_db student score event absence grapbook.sql

%mysqldump samp_db member president hist-league.sql

如果你生成準備用於定期刷新另一個數據庫內容的備份文件，你可能想用–add-drop-table選項。這告訴服務器將DROP TABLE IF EXISTS語句寫入備份文件，然後，當你取出備份文件並把它裝載進第二個數據庫時，如果表已經存在，你不會得到一個錯誤。

如果你倒出一個數據庫以便能把數據庫轉移到另一個服務器，你甚至不必創建備份文件。要保證數據庫存在於另一台主機，然後用管道傾倒數據庫，這樣mysql能直接讀取mysqldump的輸出。例如：你想從主機pit-viper.snake.net拷貝數據庫samp_db到boa.snake.net，可以這樣很容易做到：

%mysqladmin -h boa.snake.net create samp_db

%mysqldump samp_db | mysql -h boa.snake.net samp_db

以後，如果你想再次刷新boa.snake.net上的數據庫，跳過mysqladmin命令，但要對mysqldump加上–add-drop-table以避免的得到表已存在的錯誤：

%mysqldump –add-drop-table samp_db | mysql -h boa.snake.net samp_db

mysqldump其它有用的選項包括：

• –flush-logs和–lock-tables組合將對你的數據庫檢查點有幫助。–lock-tables鎖定你正在傾倒的所有表，而–flush-logs關閉並重新打開更新日誌文件，新的更新日誌將只包括從備份點起的修改數據庫的查詢。這將設置你的更新日誌檢查點位備份時間。（然而如果你有需要執行個更新的客戶，鎖定所有表對備份期間的客戶訪問不是件好事。）

• 如果你使用–flush-logs設置檢查點到備份時，有可能最好是傾倒整個數據庫。如果你傾倒單獨的文件，較難將更新日誌檢查點與備份文件同步。在恢復期間，你通常按數據庫為基礎提取更新日誌內容，對單個表沒有提取更新的選擇，所以你必須自己提取它們。

• 缺省地，mysqldump在寫入前將一個表的整個內容讀進內存。這通常確實不必要，並且實際上如果你有一個大表，幾乎是失敗的。你可用–quick選項告訴mysqldump只要它檢索出一行就寫出每一行。為了進一步優化傾倒過程，使用–opt而不是–quick。–opt選項打開其它選項，加速數據的傾倒和把它們讀回。

• 用–opt實施備份可能是最常用的方法，因為備份速度上的優勢。然而，要警告你，–opt選項確實有代價，–opt優化的是你的備份過程，不是其他客戶對數據庫的訪問。–opt選項通過一次鎖定所有表阻止任何人更新你正在傾倒的任何錶。你可在一般數據庫訪問上很容易看到其效果。當你的數據庫一般非常頻繁地使用，只是一天一次地調節備份。

• 一個具有–opt的相反效果的選項是–dedayed。該選項使得mysqldump寫出INSERT DELAYED語句而不是INSERT語句。如果你將數據文件裝入另一個數據庫並且你想是這個操作對可能出現在該數據庫中的查詢的影響最小，–delayed對此很有幫助。

• –compress選項在你拷貝數據庫到另一台機器上時很有幫助，因為它減少網絡傳輸字節的數量。下面有一個例子，注意到–compress對與遠端主機上的服務器通信的程序才給出，而不是對與本地主機連接的程序：

%mysqldump –opt samp_db | mysql –compress -h boa.snake.net samp_db

• mysqldump有很多選項，詳見《MySQL參考手冊》。

2 使用直接拷貝數據庫的備份和拷貝方法

另一種不涉及mysqldump備份數據庫和表的方式是直接拷貝數據庫表文件。典型地，這用諸如cp、tar或cpio實用程序。本文的例子使用cp。

當你使用一種直接備份方法時，你必須保證表不在被使用。如果服務器在你則正在拷貝一個表時改變它，拷貝就失去意義。

保證你的拷貝完整性的最好方法是關閉服務器，拷貝文件，然後重啟服務器。如果你不想關閉服務器，要在執行表檢查的同時鎖定服務器。如果服務器在運行，相同的制約也適用於拷貝文件，而且你應該使用相同的鎖定協議讓服務器“安靜下來”。

假設服務器關閉或你已經鎖定了你想拷貝的表，下列顯示如何將整個samp_db數據庫備份到一個備份目錄（DATADIR表示服務器的數據目錄）：

%cdDATADIR%cp -r samp_db /usr/archive/mysql

單個表可以如下備份：

%cdDATADIR/samp_db%cp member.* /usr/archive/mysql/samp_db%cp score.* /usr/archive/mysql/samp_db ….

當你完成了備份時，你可以重啟服務器（如果關閉了它）或釋放加在表上的鎖定（如果你讓服務器運行）。

要用直接拷貝文件把一個數據庫從一台機器拷貝到另一台機器上，只是將文件拷貝到另一台服務器主機的適當數據目錄下即可。要確保文件是MyIASM格式或兩台機器有相同的硬件結構，否則你的數據庫在另一台主機上有奇怪的內容。你也應該保證在另一台機器上的服務器在你正在安裝數據庫表時不訪問它們。

3 複製數據庫（Replicating Database）

複製（Replication）類似於拷貝數據庫到另一台服務器上，但它的確切含義是實時地保證兩個數據庫的完全同步。這個功能將在3.23版中出現，而且還不很成熟，因此本文不作詳細介紹。

4 用備份恢複數據

數據庫損壞的發生有很多原因，程度也不同。如果你走運，你可能僅損壞一兩個表（如掉電），如果你倒霉，你可能必須替換整個數據目錄（如磁盤損壞）。在某些情況下也需要恢復，比如用戶錯誤地刪除了數據庫或表。不管這些倒霉事件的原因，你將需要實施某種恢復。

如果表損壞但沒丟失，嘗試用myisamchk或isamchk修復它們，如果這樣的損壞可有修復程序修復，你可能根本不需要使用備份文件。關於表修復的過程，見《數據庫維護與修復》。

恢復過程涉及兩種信息源：你的備份文件和個更新日誌。備份文件將表恢復到實施備份時的狀態，然而一般表在備份與發生問題之間的時間內已經被修改，更新日誌包含了用於進行這些修改的查詢。你可以使用日誌文件作為mysql的輸入來重複查詢。這已正是為什麼要啟用更新日誌的原因。

恢復過程視你必須恢復的信息多少而不同。實際上，恢復整個數據庫比單個表跟容易，因為對於數據庫運用更新日誌比單個表容易。

4.1 恢復整個數據庫

首先，如果你想恢復的數據庫是包含授權表的mysql數據庫，你需要用–skip-grant-table選項運行服務器。否則，它會抱怨不能找到授權表。在你已經恢復表後，執行mysqladmin flush-privileges告訴服務器裝載授權標並使用它們。

• 將數據庫目錄內容拷貝到其它某個地方，如果你在以後需要它們。

• 用最新的備份文件重裝數據庫。如果你用mysqldump產生的文件，將它作為mysql的輸入。如果你用直接從數據庫拷貝來的文件，將它們直接拷回數據庫目錄，然而，此時你需要在拷貝文件之前關閉數據庫，然後重啟它。

使用更新日誌重複做備份以後的修改數據庫表的查詢。對於任何可適用的更新日誌，將它們作為mysql的輸入。指定–one-database選項使得mysql只執行你有興趣恢復的數據庫的查詢。如果你知道你需要運用所有更新日誌文件，你可以在包含日誌的目錄下使用這條命令：

% ls -t -r -1 update.[0-9]* | xargs cat | mysql –one-databasedb_name

ls命令生成更新日誌文件的一個單列列表，根據服務器產生它們的次序排序（主意：如果你修改任何一個文件，你將改變排序次序，這導致更新日誌一錯誤的次序被運用。）

很可能你會是運用某幾個更新日誌。例如，自從你備份以來產生的更新日誌被命名為update.392、update.393等等，你可以這樣重新運行：

%mysql –one-database db_name update.392

%mysql –one-database db_name update.393

…..

如果你正在實施恢復且使用更新日誌恢復由於一個錯誤建議的DROP DATABASE、DROP TABLE或DELETE語句造成丟失的信息，在運用更新日誌之前，要保證從其中刪除這些語句。

4.2 恢復單個表

恢復單個表較為複雜。如果你用一個由mysqldump生成的備份文件，並且它不包含你感興趣的表的數據，你需要從相關行中提取它們並將它們用作mysql的輸入。這是容易的部分。難的部分是從只運用於該表的更新日誌中拉出片斷。你會發覺mysql_find_rows實用程序對此很有幫助，它從更新日誌中提取多行查詢。

另一個可能性是使用另一台服務器恢復整個數據庫，然後拷貝你想要的表文件到原數據庫中。這可能真的很容易！當你將文件拷回數據庫目錄時，要確保原數據庫的服務器關閉。

至於用php語句寫mysql備份，涉及一些php課程，我也不是太懂，不好意思~~

MySQL備份的幾種常用

數據備份是數據容災的最後一道防線，即便有着兩地三中心的架構，備份也依然重要。如果備份出問題，備份時影響了交易業務，備份數據無法恢復，這些也是企業難以承受的。所以選擇合適的備份工具尤為重要。

每個企業級數據庫都會有配套的備份工具，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

MEB能做到在線熱備，備份時不影響數據庫讀寫，這是利用了InnoDB事務日誌，在備份期間持續監視redo log的變化，讀取增量變化，寫入到ibbackup_logfile，也就不需要上鎖來保障備份一致性。(對非InnoDB的文件需要上讀鎖拷貝)

如果備份期間數據庫寫入負載特別大，而寫入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 “”;

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數據庫備份和還原

MySQL數據庫備份與還原

備份和恢複數據

生成SQL腳本

在控制台使用mysqldump命令可以用來生成指定數據庫的腳本文本，但要注意，腳本文本中只包含數據庫的內容，而不會存在創建數據庫的語句！所以在恢複數據時，還需要自已手動創建一個數據庫之後再去恢複數據。

mysqldump –u用戶名 –p密碼 數據庫名生成的腳本文件路徑

現在可以在C盤下找到mydb1.sql文件了！

注意，mysqldump命令是在Windows控制台下執行，無需登錄mysql！！！

執行SQL腳本

執行SQL腳本需要登錄mysql，然後進入指定數據庫，才可以執行SQL腳本！！！

執行SQL腳本不只是用來恢複數據庫，也可以在平時編寫SQL腳本，然後使用執行SQL 腳本來操作數據庫！大家都知道，在黑屏下編寫SQL語句時，就算髮現了錯誤，可能也不能修改了。所以我建議大家使用腳本文件來編寫SQL代碼，然後執行之！

SOURCE C:\mydb1.sql

注意，在執行腳本時需要先行核查當前數據庫中的表是否與腳本文件中的語句有衝突！例如在腳本文件中存在create table a的語句，而當前數據庫中已經存在了a表，那麼就會出錯！

還可以通過下面的方式來執行腳本文件：

mysql -uroot -p123 mydb1c:\mydb1.sql

mysql –u用戶名 –p密碼 數據庫要執行腳本文件路徑

這種方式無需登錄mysql！