由于需要，從4.0直接升級到5.0，查看了一下changelog，發(fā)現(xiàn)主要有以下變化：

　　一、從 4.0 到 4.1 的主要變化

　　表。則在升級到4.1.4及更高時(shí)需要重建表，因?yàn)榇鎯Ω袷桨l(fā)生變化了 字符串根據(jù)標(biāo)準(zhǔn)sql來比較：比較之前不刪除末尾的空格，以前用末尾空格擴(kuò)展了比較短的字符串。現(xiàn)在的結(jié)果是

　　'a' > 'a　　'，以前則不這樣。可以用 mysqlcheck 來檢查一下數(shù)據(jù)表 timestamp 返回 'yyyy-mm-dd hh:mm:ss' 格式的字符串。在mysql

　　4.0中，可以增加選項(xiàng) --new 來獲得mysql 4.1中這方面的特性 在mysql

　　4.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 的主要變化

　　"check table" 語句修復(fù)數(shù)據(jù)表，如果出現(xiàn)錯(cuò)誤，就運(yùn)行 "optimize table" 或 "repair

　　table" 語句修復(fù)，甚至重新轉(zhuǎn)儲(用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對 decimal

　　的格式限制嚴(yán)格多了 在mysql 5.0.3到5.0.5之間版本的 myisam 和 innodb 表中創(chuàng)建的 decimal

　　字段升級到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 用更有效的格式來存儲 5.0.3開始，在計(jì)算 decimal 值和舍入精確值的時(shí)候采用精確數(shù)學(xué) 4.1中，float 或 double 之間的比較碰巧沒問題，但在5.0中可能就不行了 從5.0.3開始，varchar 和 varbinary 字段中末尾的空格不再刪除 增加了一個(gè)新的啟動(dòng)選項(xiàng) innodb_table_locks，它導(dǎo)致 lock table 時(shí)也可以請求

　　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

　　升級步驟如下：

　　直接拷貝 myisam 表文件

　　mysqldump

　　整個(gè)過程都很順利，新系統(tǒng)啟動(dòng)之后，發(fā)現(xiàn)如下2個(gè)問題：

　　inout

　　date_format

　　和

　　的結(jié)果完全不一樣，在 4.0 中，能兼容這兩種格式，而在 5.0 中，只能正確的使用前者了，后者則會(huì)有問題。這也應(yīng)該是上面提到的時(shí)間類型發(fā)生的變化所致。

　　到此為止，升級基本結(jié)束，大致檢查了

　　decimal