mysql 4.1 升級 mysql 5方法

一、從 4.0 到 4.1 的主要變化

如果在4.1.0到4.1.3版本的mysql教程中創建了包含 timestamp 字段的 innodb表。則在升級到4.1.4及更高時需要重建表，因為存儲格式發生變化了
字符串根據標准sql來比較：比較之前不刪除末尾的空格，以前用末尾空格擴展了比較短的字符串。現在的結果是'a' > 'at'，以前則不這樣。可以用 mysqlcheck 來檢查一下數據表
timestamp 返回 'yyyy-mm-dd hh:mm:ss' 格式的字符串。在mysql
4.0中，可以增加選項 --new 來獲得mysql 4.1中這方面的特性
在mysql4.1.1前，語句解析器不是那麼嚴格，它在處理字符串轉時間轉換時會忽略第一個數字前的其他字符。在4.1.1之後，就比較嚴格了
返回結果是 date, datetime, 或 time 類型的函數的結果會被轉換成時間型

二、再看從 4.1 到 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之後會發生崩潰
在以前，等待超時的鎖會導致 innodb
回滾當前全部事務，從5.0.13開始，就只回滾最近的sql語句了
在4.1.13/5.0.8以前，datetime 的加0後就轉換成 yyyymmddhhmmss 格式，現在變成
yyyymmddhhmmss.000000 格式了
從5.0.3開始，decimal 用更有效的格式來存儲
5.0.3開始，在計算 decimal 值和捨入精確值的時候采用精確數學
4.1中，float 或 double 之間的比較碰巧沒問題，但在5.0中可能就不行了
從5.0.3開始，varchar 和 varbinary 字段中末尾的空格不再刪除
增加了一個新的啟動選項 innodb_table_locks，它導致 lock table 時也可以請求
innodb 表鎖。這個選項默認打開，不過可能在 autocommit=1 和 lock tables
應用中會導致死鎖
看來，我只需主要關注 時間(timestamp, datetime< date, time) 和
數值型(fload, double, decimal) 這兩種類型的變化；另外，我升級過程中暫時還不需要涉及到字符集問題，因此相對輕松一些。

升級步驟如下：

執行

復制代碼 代碼如下:
flush tables with read lock;/[code]
直接拷貝 myisam 表文件

用 mysqldump 導出 innodb 類型的表
整個過程都很順利，新系統啟動之後，發現如下2個問題：

新增了關鍵字 inout，因此需要檢查表結構中還有其他什麼字段使用關鍵字了
date_format 函數要求嚴謹多了，
[code]date_format('2006/11/24 09:14:00', '%y-%m-%d %t')

和

程序代碼
date_format('2006/11/2409:14:00', '%y-%m-%d %t')

的結果完全不一樣，在 4.0 中，能兼容這兩種格式，而在 5.0 中，只能正確的使用前者了，後者則會有問題。這也應該是上面提到的時間類型發生的變化所致。