MySQL 4.0 升級到mysql 5.0的方法
更新時(shí)間：2011年02月25日 13:36:16 作者：
需要從4.0直接升級到5.0，查看了一下changelog，發(fā)現(xiàn)主要有以下變化，需要升級mysql的朋友可以參考下。
一、從 4.0 到 4.1 的主要變化
如果在4.1.0到4.1.3版本的MySQL中創(chuàng)建了包含 TIMESTAMP 字段的 InnoDB表。則在升級到4.1.4及更高時(shí)需要重建表，因?yàn)榇鎯Ω袷桨l(fā)生變化了
字符串根據(jù)標(biāo)準(zhǔn)SQL來比較：比較之前不刪除末尾的空格，以前用末尾空格擴(kuò)展了比較短的字符串。現(xiàn)在的結(jié)果是'a' > 'a\t'，以前則不這樣?？梢杂?mysqlcheck 來檢查一下數(shù)據(jù)表
TIMESTAMP 返回 'YYYY-MM-DD HH:MM:SS' 格式的字符串。在MySQL
4.0中，可以增加選項(xiàng) --new 來獲得MySQL 4.1中這方面的特性
在MySQL4.1.1前，語句解析器不是那么嚴(yán)格，它在處理字符串轉(zhuǎn)時(shí)間轉(zhuǎn)換時(shí)會忽略第一個數(shù)字前的其他字符。在4.1.1之后，就比較嚴(yán)格了
返回結(jié)果是 DATE, DATETIME, 或 TIME 類型的函數(shù)的結(jié)果會被轉(zhuǎn)換成時(shí)間型
二、再看從 4.1 到 5.0 的主要變化
InnoDB 和 MyISAM 表中空格結(jié)尾的 TEXT 字段索引順序改變了。因此需要運(yùn)行
"CHECK TABLE" 語句修復(fù)數(shù)據(jù)表，如果出現(xiàn)錯誤，就運(yùn)行 "OPTIMIZE TABLE" 或 "REPAIR
TABLE" 語句修復(fù)，甚至重新轉(zhuǎn)儲(用mysqldump)
MySQL 5.0.15開始，如何處理 BINARY 字段中填充的值已經(jīng)改變了。填充的值現(xiàn)在是
0x00 而非空格了，并且在取值的時(shí)候不會去除末尾的空格
從MySQL 5.0.3開始，DECIMAL 的實(shí)現(xiàn)方式已經(jīng)改變了，5.0對 DECIMAL
的格式限制嚴(yán)格多了
在MySQL 5.0.3到5.0.5之間版本的 MyISAM 和 InnoDB 表中創(chuàng)建的 DECIMAL
字段升級到5.0.6之后會發(fā)生崩潰
在以前，等待超時(shí)的鎖會導(dǎo)致 InnoDB
回滾當(dāng)前全部事務(wù)，從5.0.13開始，就只回滾最近的SQL語句了
在4.1.13/5.0.8以前，DATETIME 的加0后就轉(zhuǎn)換成 YYYYMMDDHHMMSS 格式，現(xiàn)在變成
YYYYMMDDHHMMSS.000000 格式了
從5.0.3開始，DECIMAL 用更有效的格式來存儲
5.0.3開始，在計(jì)算 DECIMAL 值和舍入精確值的時(shí)候采用精確數(shù)學(xué)
4.1中，F(xiàn)LOAT 或 DOUBLE 之間的比較碰巧沒問題，但在5.0中可能就不行了
從5.0.3開始，VARCHAR 和 VARBINARY 字段中末尾的空格不再刪除
增加了一個新的啟動選項(xiàng) innodb_table_locks，它導(dǎo)致 LOCK TABLE 時(shí)也可以請求
InnoDB 表鎖。這個選項(xiàng)默認(rèn)打開，不過可能在 AUTOCOMMIT=1 和 LOCK TABLES
應(yīng)用中會導(dǎo)致死鎖
看來，我只需主要關(guān)注 時(shí)間(TIMESTAMP, DATETIME< DATE, TIME) 和
數(shù)值型(FLOAD, DOUBLE, DECIMAL) 這兩種類型的變化；另外，我升級過程中暫時(shí)還不需要涉及到字符集問題，因此相對輕松一些。
升級步驟如下：
執(zhí)行
FLUSH TABLES WITH READ LOCK;/[code]
直接拷貝 MyISAM 表文件
用 mysqldump 導(dǎo)出 Innodb 類型的表
整個過程都很順利，新系統(tǒng)啟動之后，發(fā)現(xiàn)如下2個問題：
新增了關(guān)鍵字 INOUT，因此需要檢查表結(jié)構(gòu)中還有其他什么字段使用關(guān)鍵字了
DATE_FORMAT 函數(shù)要求嚴(yán)謹(jǐn)多了，
[code]DATE_FORMAT('2006/11/24 09:14:00', '%Y-%m-%d %T')
和
程序代碼
DATE_FORMAT('2006/11/2409:14:00', '%Y-%m-%d %T')
的結(jié)果完全不一樣，在 4.0 中，能兼容這兩種格式，而在 5.0 中，只能正確的使用前者了，后者則會有問題。這也應(yīng)該是上面提到的時(shí)間類型發(fā)生的變化所致。
到此為止，升級基本結(jié)束，大致檢查了 DECIMAL 類型也沒問題，剩下的就是檢查其他的了。
如果在4.1.0到4.1.3版本的MySQL中創(chuàng)建了包含 TIMESTAMP 字段的 InnoDB表。則在升級到4.1.4及更高時(shí)需要重建表，因?yàn)榇鎯Ω袷桨l(fā)生變化了
字符串根據(jù)標(biāo)準(zhǔn)SQL來比較：比較之前不刪除末尾的空格，以前用末尾空格擴(kuò)展了比較短的字符串。現(xiàn)在的結(jié)果是'a' > 'a\t'，以前則不這樣?？梢杂?mysqlcheck 來檢查一下數(shù)據(jù)表
TIMESTAMP 返回 'YYYY-MM-DD HH:MM:SS' 格式的字符串。在MySQL
4.0中，可以增加選項(xiàng) --new 來獲得MySQL 4.1中這方面的特性
在MySQL4.1.1前，語句解析器不是那么嚴(yán)格，它在處理字符串轉(zhuǎn)時(shí)間轉(zhuǎn)換時(shí)會忽略第一個數(shù)字前的其他字符。在4.1.1之后，就比較嚴(yán)格了
返回結(jié)果是 DATE, DATETIME, 或 TIME 類型的函數(shù)的結(jié)果會被轉(zhuǎn)換成時(shí)間型
二、再看從 4.1 到 5.0 的主要變化
InnoDB 和 MyISAM 表中空格結(jié)尾的 TEXT 字段索引順序改變了。因此需要運(yùn)行
"CHECK TABLE" 語句修復(fù)數(shù)據(jù)表，如果出現(xiàn)錯誤，就運(yùn)行 "OPTIMIZE TABLE" 或 "REPAIR
TABLE" 語句修復(fù)，甚至重新轉(zhuǎn)儲(用mysqldump)
MySQL 5.0.15開始，如何處理 BINARY 字段中填充的值已經(jīng)改變了。填充的值現(xiàn)在是
0x00 而非空格了，并且在取值的時(shí)候不會去除末尾的空格
從MySQL 5.0.3開始，DECIMAL 的實(shí)現(xiàn)方式已經(jīng)改變了，5.0對 DECIMAL
的格式限制嚴(yán)格多了
在MySQL 5.0.3到5.0.5之間版本的 MyISAM 和 InnoDB 表中創(chuàng)建的 DECIMAL
字段升級到5.0.6之后會發(fā)生崩潰
在以前，等待超時(shí)的鎖會導(dǎo)致 InnoDB
回滾當(dāng)前全部事務(wù)，從5.0.13開始，就只回滾最近的SQL語句了
在4.1.13/5.0.8以前，DATETIME 的加0后就轉(zhuǎn)換成 YYYYMMDDHHMMSS 格式，現(xiàn)在變成
YYYYMMDDHHMMSS.000000 格式了
從5.0.3開始，DECIMAL 用更有效的格式來存儲
5.0.3開始，在計(jì)算 DECIMAL 值和舍入精確值的時(shí)候采用精確數(shù)學(xué)
4.1中，F(xiàn)LOAT 或 DOUBLE 之間的比較碰巧沒問題，但在5.0中可能就不行了
從5.0.3開始，VARCHAR 和 VARBINARY 字段中末尾的空格不再刪除
增加了一個新的啟動選項(xiàng) innodb_table_locks，它導(dǎo)致 LOCK TABLE 時(shí)也可以請求
InnoDB 表鎖。這個選項(xiàng)默認(rèn)打開，不過可能在 AUTOCOMMIT=1 和 LOCK TABLES
應(yīng)用中會導(dǎo)致死鎖
看來，我只需主要關(guān)注 時(shí)間(TIMESTAMP, DATETIME< DATE, TIME) 和
數(shù)值型(FLOAD, DOUBLE, DECIMAL) 這兩種類型的變化；另外，我升級過程中暫時(shí)還不需要涉及到字符集問題，因此相對輕松一些。
升級步驟如下：
執(zhí)行
復(fù)制代碼 代碼如下:
FLUSH TABLES WITH READ LOCK;/[code]
直接拷貝 MyISAM 表文件
用 mysqldump 導(dǎo)出 Innodb 類型的表
整個過程都很順利，新系統(tǒng)啟動之后，發(fā)現(xiàn)如下2個問題：
新增了關(guān)鍵字 INOUT，因此需要檢查表結(jié)構(gòu)中還有其他什么字段使用關(guān)鍵字了
DATE_FORMAT 函數(shù)要求嚴(yán)謹(jǐn)多了，
[code]DATE_FORMAT('2006/11/24 09:14:00', '%Y-%m-%d %T')
和
程序代碼
DATE_FORMAT('2006/11/2409:14:00', '%Y-%m-%d %T')
的結(jié)果完全不一樣，在 4.0 中，能兼容這兩種格式，而在 5.0 中，只能正確的使用前者了，后者則會有問題。這也應(yīng)該是上面提到的時(shí)間類型發(fā)生的變化所致。
到此為止，升級基本結(jié)束，大致檢查了 DECIMAL 類型也沒問題，剩下的就是檢查其他的了。
相關(guān)文章
這篇文章主要介紹了Mysql的基本函數(shù)與自定義函數(shù)用法,具有很好的參考價(jià)值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-06-06
淺談Mysql insert on duplicate key 死鎖問
本文介紹了在并發(fā)場景下的 insert on duplicate key update sql 出現(xiàn)的死鎖，經(jīng)過分析發(fā)現(xiàn)這種sql確實(shí)比較容易造成死鎖，這篇文章就從分析死鎖展開，到最終如何解決這樣的問題 分享相應(yīng)的思路，感興趣的可以了解一下2022-05-05
事務(wù)處理在各種管理系統(tǒng)中都有著廣泛的應(yīng)用，比如人員管理系統(tǒng)，很多同步數(shù)據(jù)庫操作大都需要用到事務(wù)處理。這篇文章主要介紹了MySQL事務(wù)處理,需要的朋友可以參考下2014-06-06
MySQL大表重復(fù)字段應(yīng)該如何查詢到呢?這是很多人都遇到的問題，下面就教您一個MySQL大表重復(fù)字段的查詢方法，供您參考2012-12-12
數(shù)據(jù)結(jié)構(gòu)-樹（三）：多路搜索樹B樹、B+樹
這篇文章主要介紹了多路搜索樹B樹、B+樹，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2019-04-04
這篇文章主要為大家詳細(xì)介紹了mysql 5.7.16 ZIP包安裝配置教程，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2019-08-08
數(shù)據(jù)庫的一個難題是無法將SQL語句的執(zhí)行結(jié)果轉(zhuǎn)換為想要的格式。本節(jié)，我們將通過學(xué)習(xí)格式轉(zhuǎn)換中具有代表性的行列轉(zhuǎn)換和嵌套式側(cè)欄的生成方法，深入理解一下其中有重要作用的外連接2022-04-04
Ubuntu系統(tǒng)安裝mysql超詳細(xì)步驟
這篇文章主要給大家介紹了關(guān)于Ubuntu系統(tǒng)安裝mysql的相關(guān)資料,現(xiàn)在的軟件越來越好安裝,尤其是在ubuntu下安裝軟件,文中通過圖文介紹的非常詳細(xì),需要的朋友可以參考下2023-09-09
mysql 關(guān)鍵詞相關(guān)度排序方法詳細(xì)示例分析
以下是對mysql關(guān)鍵詞相關(guān)度排序方法進(jìn)行了詳細(xì)的分析介紹，需要的朋友可以過來參考下2013-08-08
本篇文章旨在介紹如何使用數(shù)據(jù)處理函數(shù)，和其他大多數(shù)計(jì)算機(jī)語言語言，MYSQL支持利用函數(shù)來處理數(shù)據(jù)，函數(shù)也就是一般在數(shù)據(jù)上執(zhí)行，它給數(shù)據(jù)的轉(zhuǎn)換和處理提供了方便2022-05-05