MySQL 4.0 升級到5.0
日期:2008-07-04 作者:喜騰小二 來源:PHPChina
由於需要，從4.0直接升級到5.0，檢視了一下changelog，發現主要有以下變化：
一、從 4.0 到 4.1 的主要變化
- 如果在4.1.0到4.1.3版本的MySQL中建立了包含 TIMESTAMP 欄位的 InnoDB
表。則在升級到4.1.4及更高時需要重建表，因為存儲格式發生變化了
- 字串根據標準SQL來比較：比較之前不移除末尾的空格，以前用末尾空格延伸了比較短的字串。現在的結果是
'a' > 'a'，以前則不這樣。可以用 mysqlcheck 來檢查一下資料表
- TIMESTAMP 返回 'YYYY-MM-DD HH:MM:SS' 格式的字串。在MySQL
4.0中，可以增加選項 --new 來獲得MySQL 4.1中這方麵的特性
- 在MySQL
4.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;
直接拷貝 MyISAM 表檔案
- 用
mysqldump匯出 Innodb 類型的表
整個過程都很順利，新係統啓動之後，發現如下2個問題：
- 新增了關鍵字
INOUT，因此需要檢查表結構中還有其他什麼欄位使用關鍵字了
DATE_FORMAT函式要求嚴謹多了，
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 中，隻能正確的使用前者了，後者則會有問題。這也應該是上麵提到的時間類型發生的變化所緻。
到此為止，升級基本結束，大緻檢查了 DECIMAL 類型也沒問題，剩下的就是檢查其他的了。
Copyright 2004 - 2011 SYSTN.COM
