MySQL 4.0 升級(jí)到mysql 5.0的方法
更新時(shí)間:2011年02月25日 13:36:16 作者:
需要從4.0直接升級(jí)到5.0,查看了一下changelog,發(fā)現(xiàn)主要有以下變化,需要升級(jí)mysql的朋友可以參考下。
一、從 4.0 到 4.1 的主要變化
如果在4.1.0到4.1.3版本的MySQL中創(chuàng)建了包含 TIMESTAMP 字段的 InnoDB表。則在升級(jí)到4.1.4及更高時(shí)需要重建表,因?yàn)榇鎯?chǔ)格式發(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í)會(huì)忽略第一個(gè)數(shù)字前的其他字符。在4.1.1之后,就比較嚴(yán)格了
返回結(jié)果是 DATE, DATETIME, 或 TIME 類型的函數(shù)的結(jié)果會(huì)被轉(zhuǎn)換成時(shí)間型
二、再看從 4.1 到 5.0 的主要變化
InnoDB 和 MyISAM 表中空格結(jié)尾的 TEXT 字段索引順序改變了。因此需要運(yùn)行
"CHECK TABLE" 語句修復(fù)數(shù)據(jù)表,如果出現(xiàn)錯(cuò)誤,就運(yùn)行 "OPTIMIZE TABLE" 或 "REPAIR
TABLE" 語句修復(fù),甚至重新轉(zhuǎn)儲(chǔ)(用mysqldump)
MySQL 5.0.15開始,如何處理 BINARY 字段中填充的值已經(jīng)改變了。填充的值現(xiàn)在是
0x00 而非空格了,并且在取值的時(shí)候不會(huì)去除末尾的空格
從MySQL 5.0.3開始,DECIMAL 的實(shí)現(xiàn)方式已經(jīng)改變了,5.0對(duì) DECIMAL
的格式限制嚴(yán)格多了
在MySQL 5.0.3到5.0.5之間版本的 MyISAM 和 InnoDB 表中創(chuàng)建的 DECIMAL
字段升級(jí)到5.0.6之后會(huì)發(fā)生崩潰
在以前,等待超時(shí)的鎖會(huì)導(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 用更有效的格式來存儲(chǔ)
5.0.3開始,在計(jì)算 DECIMAL 值和舍入精確值的時(shí)候采用精確數(shù)學(xué)
4.1中,F(xiàn)LOAT 或 DOUBLE 之間的比較碰巧沒問題,但在5.0中可能就不行了
從5.0.3開始,VARCHAR 和 VARBINARY 字段中末尾的空格不再刪除
增加了一個(gè)新的啟動(dòng)選項(xiàng) innodb_table_locks,它導(dǎo)致 LOCK TABLE 時(shí)也可以請(qǐng)求
InnoDB 表鎖。這個(gè)選項(xiàng)默認(rèn)打開,不過可能在 AUTOCOMMIT=1 和 LOCK TABLES
應(yīng)用中會(huì)導(dǎo)致死鎖
看來,我只需主要關(guān)注 時(shí)間(TIMESTAMP, DATETIME< DATE, TIME) 和
數(shù)值型(FLOAD, DOUBLE, DECIMAL) 這兩種類型的變化;另外,我升級(jí)過程中暫時(shí)還不需要涉及到字符集問題,因此相對(duì)輕松一些。
升級(jí)步驟如下:
執(zhí)行
FLUSH TABLES WITH READ LOCK;/[code]
直接拷貝 MyISAM 表文件
用 mysqldump 導(dǎo)出 Innodb 類型的表
整個(gè)過程都很順利,新系統(tǒng)啟動(dòng)之后,發(fā)現(xiàn)如下2個(gè)問題:
新增了關(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 中,只能正確的使用前者了,后者則會(huì)有問題。這也應(yīng)該是上面提到的時(shí)間類型發(fā)生的變化所致。
到此為止,升級(jí)基本結(jié)束,大致檢查了 DECIMAL 類型也沒問題,剩下的就是檢查其他的了。
如果在4.1.0到4.1.3版本的MySQL中創(chuàng)建了包含 TIMESTAMP 字段的 InnoDB表。則在升級(jí)到4.1.4及更高時(shí)需要重建表,因?yàn)榇鎯?chǔ)格式發(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í)會(huì)忽略第一個(gè)數(shù)字前的其他字符。在4.1.1之后,就比較嚴(yán)格了
返回結(jié)果是 DATE, DATETIME, 或 TIME 類型的函數(shù)的結(jié)果會(huì)被轉(zhuǎn)換成時(shí)間型
二、再看從 4.1 到 5.0 的主要變化
InnoDB 和 MyISAM 表中空格結(jié)尾的 TEXT 字段索引順序改變了。因此需要運(yùn)行
"CHECK TABLE" 語句修復(fù)數(shù)據(jù)表,如果出現(xiàn)錯(cuò)誤,就運(yùn)行 "OPTIMIZE TABLE" 或 "REPAIR
TABLE" 語句修復(fù),甚至重新轉(zhuǎn)儲(chǔ)(用mysqldump)
MySQL 5.0.15開始,如何處理 BINARY 字段中填充的值已經(jīng)改變了。填充的值現(xiàn)在是
0x00 而非空格了,并且在取值的時(shí)候不會(huì)去除末尾的空格
從MySQL 5.0.3開始,DECIMAL 的實(shí)現(xiàn)方式已經(jīng)改變了,5.0對(duì) DECIMAL
的格式限制嚴(yán)格多了
在MySQL 5.0.3到5.0.5之間版本的 MyISAM 和 InnoDB 表中創(chuàng)建的 DECIMAL
字段升級(jí)到5.0.6之后會(huì)發(fā)生崩潰
在以前,等待超時(shí)的鎖會(huì)導(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 用更有效的格式來存儲(chǔ)
5.0.3開始,在計(jì)算 DECIMAL 值和舍入精確值的時(shí)候采用精確數(shù)學(xué)
4.1中,F(xiàn)LOAT 或 DOUBLE 之間的比較碰巧沒問題,但在5.0中可能就不行了
從5.0.3開始,VARCHAR 和 VARBINARY 字段中末尾的空格不再刪除
增加了一個(gè)新的啟動(dòng)選項(xiàng) innodb_table_locks,它導(dǎo)致 LOCK TABLE 時(shí)也可以請(qǐng)求
InnoDB 表鎖。這個(gè)選項(xiàng)默認(rèn)打開,不過可能在 AUTOCOMMIT=1 和 LOCK TABLES
應(yīng)用中會(huì)導(dǎo)致死鎖
看來,我只需主要關(guān)注 時(shí)間(TIMESTAMP, DATETIME< DATE, TIME) 和
數(shù)值型(FLOAD, DOUBLE, DECIMAL) 這兩種類型的變化;另外,我升級(jí)過程中暫時(shí)還不需要涉及到字符集問題,因此相對(duì)輕松一些。
升級(jí)步驟如下:
執(zhí)行
復(fù)制代碼 代碼如下:
FLUSH TABLES WITH READ LOCK;/[code]
直接拷貝 MyISAM 表文件
用 mysqldump 導(dǎo)出 Innodb 類型的表
整個(gè)過程都很順利,新系統(tǒng)啟動(dòng)之后,發(fā)現(xiàn)如下2個(gè)問題:
新增了關(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 中,只能正確的使用前者了,后者則會(huì)有問題。這也應(yīng)該是上面提到的時(shí)間類型發(fā)生的變化所致。
到此為止,升級(jí)基本結(jié)束,大致檢查了 DECIMAL 類型也沒問題,剩下的就是檢查其他的了。
您可能感興趣的文章:
相關(guān)文章
MySQL數(shù)據(jù)庫索引原理及優(yōu)化策略
MySQL數(shù)據(jù)庫索引是一種數(shù)據(jù)結(jié)構(gòu),用于提高數(shù)據(jù)查詢的效率,加快數(shù)據(jù)檢索的速度。索引基于樹結(jié)構(gòu)實(shí)現(xiàn),可以通過B+樹等算法來優(yōu)化索引效率。MySQL中常見的索引類型包括主鍵索引、唯一索引、普通索引、全文索引等2023-04-04防止MySQL重復(fù)插入數(shù)據(jù)的三種方法
在MySQL進(jìn)行數(shù)據(jù)插入操作時(shí),總是會(huì)考慮是否會(huì)插入重復(fù)數(shù)據(jù),之前的操作都是先根據(jù)主鍵或者唯一約束條件進(jìn)行查詢,有就進(jìn)行更新沒有就進(jìn)行插入。代碼反復(fù)效率低下。2020-09-09mysql中insert與select的嵌套使用解決組合字段插入問題
本節(jié)主要介紹了mysql中insert與select的嵌套使用解決組合字段插入問題,需要的朋友可以參考下2014-07-07mysql視圖之確保視圖的一致性(with check option)操作詳解
這篇文章主要介紹了mysql視圖之確保視圖的一致性(with check option)操作,結(jié)合實(shí)例形式詳細(xì)分析了視圖的一致性操作原理、實(shí)現(xiàn)技巧與操作注意事項(xiàng),需要的朋友可以參考下2019-12-12