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 類型也沒問題,剩下的就是檢查其他的了。

<<<返回技術中心

技術文章

站內新聞

我要啦免费统计