原文: MySQL?升級方法指南大全

通常，從一個發布版本升級到另一個版本時，我們建議按照順序來升級版本。例如，想要升級 MySQL 3.23 時，先升級到 MySQL 4.0，而不是直接升級到 MySQL 4.1 或 MySQL 5.0。
如果都是比較新的版本的升級可以參考下面的文章，
MySQL數據庫的版本更新很快，新的特性也隨之不斷的更新，更主要的是解決了很多影響我們應用的BUG，為了讓我們的MySQL變得更美好，我們有必要去給它升級，盡管你會說它現在已經跑得很好很穩定完全夠用了。下面我們來看看幾種常用的升級方法。

介紹之前，我們先做一些聲明，MySQL采用二進制包來安裝，升級都是在同一臺DB Server上操作。

第一種，很簡單，適用于任何存儲引擎。

1. 下載并安裝好新版本的MySQL數據庫，并將其端口改為3307（避免和舊版本的3306沖突），啟動服務。

2. 在新版本下創建同名數據庫。

# mysqldump -p3307 -uroot create mysqlsystems_com

3. 在舊版本下備份該數據庫。

# mysqldump -p3306 -uroot mysqlsystems_com > mysqlsystems_com.bk

Note: 你也可以加上–opt選項，這樣可以使用優化方式將你的數據庫導出，減少未知的問題。

4. 將導出的數據庫備份導入到新版本的MySQL數據庫中。

# mysql -p3307 -uroot mysqlsystems_com < mysqlsystems_com.bk

5. 再將舊版本數據庫中的data目錄下的mysql數據庫全部覆蓋到新版本中。

# cp -R /opt/mysql-5.1/data/mysql /opt/mysql-5.4/data

Note: 大家也都知道這個默認數據庫的重要性。

6. 在新版下執行mysql_upgrade命令，其實這個命令包含一下三個命令：

# mysqlcheck –check-upgrade –all-databases –auto-repair
# mysql_fix_privilege_tables
# mysqlcheck –all-databases –check-upgrade –fix-db-names –fix-table-names

Note: 在每一次的升級過程中，mysql_upgrade這個命令我們都應該去執行，它通過mysqlcheck命令幫我們去檢查表是否兼容新版本的數據庫同時作出修復，還有個很重要的作用就是使用mysql_fix_privilege_tables命令去升級權限表。

7. 關閉舊版本，將新版的數據庫的使用端口改為3306，重新啟動新版本MySQL數據庫。到此，一個簡單環境下的數據庫升級就結束了。

第二種，同樣適用任何存儲引擎。

1. 同樣先安裝好新版本的MySQL。

2. 在舊版本中，備份數據庫。

# mkdir /opt/mysqlsystems_bk ; mysqldump -p3306 -uroot –tab=/opt/mysqlsystems_bk mysqlsystems_com

Note: –tab選項可以在備份目錄mysqlsystems_bk下生成后綴為*.sql和*.txt的兩類文件；其中，.sql保存了創建表的SQL語句而.txt保存著原始數據。

3. 接下來在新版本的數據庫下更新數據。

# mysqladmin -p3307 -uroot create mysqlsystems_com

# cat /opt/mysqlsystems_bk*.TRG
啟動服務器，倒入觸發器：
mysql> delimiter // ;
mysql> source /tmp/triggers.sql //
不兼容的變化：MySQL 5.1.6引進了觸發器權限機制。以前，創建觸發器需要有 SUPER 權限，現在，這個操作只需要有 TRIGGER 權限。這改善了權限安全狀況
一些MySQL 5.1中作為保留關鍵字在MySQL 5.0中并沒有作為保留關鍵字
新引入了 "INSTALL PLUGIN" 和 "UNINSTALL PLUGIN" 語句用于操作API插件。同樣，創建 FULLTEXT 索引時，可以用 "WITH PARSER" 子句關聯解析器插件
3、從 MySQL 4.1 升級到 MySQL 5.0

服務器部分：

不兼容的變化：InnoDB 和 MyISAM 表中空格結尾的 TEXT 字段索引順序改變了。因此需要運行 "CHECK TABLE" 語句修復數據表，如果出現錯誤，就運行 "OPTIMIZE TABLE" 或 "REPAIR TABLE" 語句修復，甚至重新轉儲(用mysqldump)
不兼容的變化：從MySQL 5.0.15開始，如何處理 BINARY 字段中填充的值已經改變了。填充的值現在是 0x00 而非空格了，并且在取值的時候不會去除末尾的空格
不兼容的變化：從MySQL 5.0.3開始，DECIMAL 的實現方式已經改變了，5.0對 DECIMAL 的格式限制嚴格多了
不兼容的變化：在MySQL 5.0.3到5.0.5之間版本的 MyISAM 和 InnoDB 表中創建的 DECIMAL 字段升級到5.0.6之后會發生崩潰
不兼容的變化：從5.0.3開始，除非和主函數之間有輔助的符號鏈接，否則服務器將不再默認地加載用戶自定義函數(UDFs)，也可以通過 --allow-suspicious-udfs 選項來啟用
不兼容的變化：5.0中禁用了更新日志(update log) ，不過可以用二進制日志(binary log)來代替它
不兼容的變化：5.0中不再支持 ISAM 類型存儲引擎(作者：可以通過重新編譯源代碼支持，不過非常不建議這么做)
不兼容的變化：5.0中不再支持 MyISAM 的 RAID 選項，可以用 mysqldump 導出舊表然后重新導回去實現升級
在5.0.6中，記錄存儲過程和觸發器的二進制日志發生了一些變化，詳見手冊的 "17.4 Binary Logging of Stored Routines and Triggers"
SQL部分：

不兼容的變化：從5.0.12開始，自然連接和使用 USING 的連接，包括外部連接的衍生形式，都按照SQL:2003標準來處理了；這個變化導致減少了自然連接和使用 USING 的連接產生的結果字段數，并且還將按照更合理的順序顯示這些字段，逗號比較符的優先順序和 JOIN, LEFT JOIN 中的一樣了
不兼容的變化：在以前，等待超時的鎖會導致 InnoDB 回滾當前全部事務，從5.0.13開始，就只回滾最近的SQL語句了
不兼容的變化：觸發器的變化，跟前面講到的一樣
不兼容的變化：從5.0.15開始，CHAR() 函數返回二進制字符串，而不是按照連接字符集格式的字符串。子句 USING charset_name 可以自定義返回結果的字符集
不兼容的變化：在5.0.13以前，NOW() 和 SYSDATE() 返回的結果一樣。但從5.0.13開始，SYSDATE() 返回的是語句執行點的時間，這就可能和 NOW() 返回的結果不一樣了，不過可以用 --sysdate-is-now 選項讓 SYSDATE() 作為 NOW() 的同名函數
不兼容的變化：在5.0.13以前，GREATEST(x,NULL) 和 LEAST(x,NULL) 如果 x 不是 NULL 值，則返回 x 。從5.0.13開始，只要任何參數是 NULL ，就返回 NULL，跟Oracle一樣
不兼容的變化：在4.1.13/5.0.8以前，DATETIME 的加0后就轉換成 YYYYMMDDHHMMSS 格式，現在變成 YYYYMMDDHHMMSS.000000 格式了
不兼容的變化：在4.1.12/5.0.6中，語句 LOAD DATA INFILE 和 SELECT ... INTO OUTFILE 中，當 FIELDS TERMINATED BY 和 FIELDS ENCLOSED BY 的值都是空的時候，結果就被改變了。以前，字段都按照它顯示的寬度來讀寫的?，F在變成按照足夠保存字段值的寬度來讀寫它。然而，對MySQL 4.0.12/5.0.6來說，那些在它們之前導出來的文件可能無法正確用 LOAD DATA INFILE 語句導入
一些MySQL 5.0中作為保留關鍵字在MySQL 4.1中并沒有作為保留關鍵字
從5.0.3開始，DECIMAL 用更有效的格式來存儲
5.0.3開始，在計算 DECIMAL 值和舍入精確值的時候采用精確數學
4.1中，FLOAT 或 DOUBLE 之間的比較碰巧沒問題，但在5.0中可能就不行了
從5.0.3開始，VARCHAR 和 VARBINARY 字段中末尾的空格不再刪除
從5.0.3開始，BIT 是一個獨立的數據類型了，不再是 TINYINT(1) 的同名詞了
MySQL 5.0.2增加了一些SQL模式以使對排除包含非法或者缺失值得記錄有著更嚴格的控制
從5.0.2開始，關鍵字 SCHEMA 和 SCHEMAS 被認為分別是 DATABASE 和 DATABASES 的同名詞
5.0中用戶變量對大小寫不敏感，而4.1中則不然
增加了一個新的啟動選項 innodb_table_locks，它導致 LOCK TABLE 時也可以請求 InnoDB 表鎖。這個選項默認打開，不過可能在 AUTOCOMMIT=1 和 LOCK TABLES 應用中會導致死鎖
C API部分：

不兼容的變化：由于5.0中 DECIMAL 數據類型的實現方式發生了變化，因此如果使用就版本的庫文件需要注意這個問題
不兼容的變化：在5.0.3中，ER_WARN_DATA_TRUNCATED 警告符號改名為 WARN_DATA_TRUNCATED 了
MYSQL 結構體中的 reconnect 標志被 mysql_real_connect() 設為 0。
4、從 MySQL 4.0 升級到 MySQL 4.1

服務器部分：

不兼容的變化：以下好幾個都是需要重建數據表的，可以使用 mysqldump 導出表后重新導回去

如果在4.1.0到4.1.3版本的MySQL中創建了包含 TIMESTAMP 字段的 InnoDB 表。則在升級到4.1.4及更高時需要重建表，因為存儲格式發生變化了
從4.1.3開始，InnoDB 表采用同一種字符集比較函數來比較那些 非latin1_swedish_ci 字符集且不是 BINARY 的字符串
如果在4.1.0到4.1.5版本的MySQl中對 UTF8 字段或者其他多字節字段作了前綴索引，則在升級到4.1.6及更高時必須重建表
如果在4.1之前，數據庫、表、字段、約束名中使用了重音字符(字節值是128到255的字符)，那么不能直接升級到4.1。因為4.1使用 UTF8 來存儲元數據名。
字符串根據標準SQL來比較：比較之前不刪除末尾的空格，以前用末尾空格擴展了比較短的字符串?，F在的結果是 'a' > 'a\t'，以前則不這樣?？梢杂?mysqlcheck 來檢查一下數據表
MyISAM 現在使用更好的校驗和算法了
不兼容的變化：MySQL把字符串類型字段的長度定義理解為字符長度而不是字節長度。
重要提示：MySQL 4.1用 UTF8 字符集存儲數據表名和字段名。如果有用標準 7字節 US-ASCII 范圍之外的字符作為表名/字段名的話，需要重建表
重要提示：升級到4.1.1或更高后，就很難降級回到4.0或4.1了，因為 InnoDB 使用了多個表空間的緣故
不兼容的變化：MySQL 4.1.13支持讓每個連接設定時區，因此系統變量 timezone 改成 system_time_zone
所有的數據表和非二進制字符串(CHAR, VARCHAR, 和 TEXT)的字段都有字符集，二進制字符串字段包括 BINARY, VARBINARY, 和 BLOB
MySQL4.0中，如果有字段類型為 CHAR BINARY 或 VARCHAR BINARY，則它們會被當作二進制字符串類型
如果數據表的字段中存儲著MySQL 4.1直接就能支持的字符集字符數據時，則可以將這個字段的值轉換成由合適的字符集存儲
MySQL 4.1中對數據結構描述文件 .frm 的格式稍作改進，新版本能兼容這個新格式，但是舊版本則不能
windows下的服務器啟動時增加 --shared-memory 選項即可支持從本地客戶端連接時使用共享內存
不兼容的變化：從MySQL 4.1.1開始，對用戶自定義函數集合接口發生了很大改進
不兼容的變化：從4.1.10a開始，除非和主函數之間有輔助的鏈接，否則服務器將不再默認地加載用戶自定義函數(UDFs)，也可以通過 --allow-suspicious-udfs 選項來啟用
客戶端部分：

mysqldump 默認啟用 --opt 和 --quote-names 選項
SQL部分：

不兼容的變化：字符串根據標準SQL來比較，如上面的"服務器變化"部分中提到的
不兼容的變化：TIMESTAMP 返回 'YYYY-MM-DD HH:MM:SS' 格式的字符串。在MySQL 4.0中，可以增加選項 --new 來獲得MySQL 4.1中這方面的特性
不兼容的變化：二進制數據例如 0xFFDF 被當成字符串而非數字
不兼容的變化：在MySQL 4.1.1前，語句解析器不是那么嚴格，它在處理字符串轉時間轉換時會忽略第一個數字前的其他字符。在4.1.1之后，就比較嚴格了
不兼容的變化：在MySQL 4.1.2，SHOW TABLE STATUS 結果的 Type 字段改名為 Engine 了
當執行多表刪除語句時，要刪除的表只能使用它的別名，而不能用真實表名
返回結果是 DATE, DATETIME, 或 TIME 類型的函數的結果會被轉換成時間型
AUTO_INCREMENT 字段不能設定 默認(DEFAULT) 值了
LIMIT 不再接受負數參數了
SERIALIZE 不再是 sql_mode 變量的有效值了，它的取代值是 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
C API部分：

MySQL 4.1中的密碼哈希算法做了改進以提升安全性，不過會導致兼容性問題。使用MySQL 4.0及更早版本的客戶端庫文件會發生問題。

不兼容的變化：mysql_shutdown() 函數增加一個參數：SHUTDOWN-level
某些函數例如 mysql_real_query() 發生錯誤時返回 1 而非 -1
密碼處理部分：

MySQL 4.1中的密碼哈希算法做了改進以提升安全性，不過會導致兼容性問題。使用MySQL 4.0及更早版本的客戶端庫文件會發生問題。解決辦法有：

升級客戶端庫文件到4.1(不用升級服務器端庫文件)
運行 mysql_fix_privilege_tables 腳本來加寬 user 表中的 Password 字段值，以適應新的哈希算法。如果想要允許4.1以下的客戶端還能連接到服務器，那么服務器運行時要增加參數 --old-passwords
5、附錄

1、) 在Windows平臺上升級MySQL步驟：

備份舊數據
停止舊服務器
從windows的系統服務中刪掉mysql服務，用如下命令：
C:\> C:\mysql\bin\mysqld --remove用可執行安裝文件方式安裝mysql，或者解壓可直接執行的二進制壓縮包來安裝
重新注冊mysql服務，用如下命令：
C:\> C:\mysql\bin\mysqld --install 重啟服務器
其他的問題詳見上面提到的各種升級中會碰到的情況
2、) 升級授權表

升級授權表之前一定要備份好 mysql 數據庫，以備升級失敗時使用舊的授權表。

在unix或類unix系統中，運行 mysql_fix_privilege_tables 腳本來升級授權表：

shell> mysql_fix_privilege_tables 必須在 mysqld 運行著的時候執行這個腳本，它嘗試使用 root 帳號來連接服務器；因此，當 root 需要密碼時，用如下方式來指定密碼：

shell> mysql_fix_privilege_tables --password=root_password 在 MySQL 4.1之前，則是用如下形式來指定密碼：

shell> mysql_fix_privilege_tables root_password
接下來 mysql_fix_privilege_tables 腳本會升級授權表，在這個過程中可能會有一些 Duplicate column name 警告信息，無需理會它們。待它運行完之后，重啟一下服務器即可。

在windows平臺上，授權表想要升級到4.0.15并不容易。從4.0.15開始，發行版中包含一個sql腳本：mysql_fix_privilege_tables.sql，用 mysql 客戶端運行它來升級授權表，運行類似如下命令：

C:\> C:\mysql\bin\mysql -u root -p mysql
mysql> SOURCE C:/mysql/scripts/mysql_fix_privilege_tables.sql
把上面提到的目錄改成真實的目錄。

3、) 升級同步

請查看我翻譯的文檔"6.6 升級同步"

4、) mysql_update MySQL升級時檢查數據表

每次升級的時候都必須運行 mysql_upgrade 腳本。它檢查了當前版本的MySQL下的所有數據庫表的不兼容性，就會檢查這些表；并且發現有問題時，也會修復這些表。mysql_update 同時升級了系統表，因此可以兼容新的權限機制并且使用新增的權限。

由于 mysql_update 會把檢查過和修復過的表都標記上當前的MySQL版本號，因而保證了下一次在同一個MySQL版本下運行這個腳本時，都會再次報告哪些表需要修復或檢查。

它還會把MySQL的版本號記錄在數據文件目錄下的一個文件中：mysql_upgrade.info。這個文件用于標識當前發布版本檢查表時哪些表可以略過，檢查時想要忽略這個文件，只需附加上 --force 選項。

為了能檢查和修復數據表，并且升級系統表，mysql_update 執行了一下命令：

mysqlcheck --check-upgrade --all-databases --auto-repair
mysql_fix_privilege_tables
mysql_update 目前只支持類unix平臺；在windows下，需要手工執行 mysqlcheck 命令，升級授權表請看附錄"升級授權表"。

執行 mysql_update 時，MySQL服務器必須運行著，它有以下幾個參數：

--help
顯示幫助信息并且退出

--basedir=path
設定MySQL的安裝路徑

--datadir=path
設定MySQL的數據文件路徑

--force
告訴 mysql_update，在檢查時忽略是否存在 mysql_upgrade.info 文件，強行檢查該版本的MySQL數據表，不管是否已經檢查過了

--user=user_name, -u user_name
連接到MySQL的用戶名，默認是 root

--verbose
冗余模式。發生問題時打印出更多的信息

其他的選項諸如 --password[=password] 是要傳遞給 mysqlcheck 和 mysql_fix_privilege_tables 腳本的，并不是必須的。

MySQL?升級方法指南大全