MySQL 4 0 公升級到mysql 5 0的方法

2022-09-30 00:12:21 字數 2156 閱讀 6838

一、從 4.0 到 4.1 的主要變化

如果在4.1.0到4.1.3版本的mysql中建立了包含 timestamp 欄位的 innodb表。則在公升級到4.1.4及更高時需要重建表,因為儲存格式發生變化了

字串根據標準sql來比較:比較之前不刪除末尾的空格,以前用末尾空格擴充套件了比較短的字串。現在的結果是'a' > 'a\t',以前則不這樣。可以用 mysqlcheck 來檢查一下資料表

timestamp 返回 'yyyy-mm-dd hh:mm:ss' 格式的字串。在mysql

4.0中,可以增加選項 --new 來獲得mysql 4.1中這方面的特性

在mysql4.1.1前,語句解析器不是那麼嚴格,它在處理字串轉時間轉換時會忽略第乙個數字前的其他字元。在4.1.1之後,就比較嚴格了

返回結果是 date, datetim程式設計客棧e, 或 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 和 locemvvcivznek 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 中,只能正確的使用前者了,後者則會有問題。這也應該是上面提到的時間型別發www.cppcns.com生的變化所致。

到此為止,公升級基本結束,大致檢查了 decimal 型別也沒問題,剩下的就是檢查其他的了。

本文標題: mysql 4.0 公升級到mysql 5.0的方法

本文位址: /shujuku/mysql/62072.html

MySQL,4 0公升級到5 1遇到乙個問題

1 資料庫資料量暴增,對比其他業務類似的資料庫發現某個表的資料量異常,最後確定了乙個重複遷移資料的bug.120301 17 30 43 error column count of mysql.db is wrong.expected 22,found 15.the table is probabl...

MySQL,4 0公升級到5 1遇到乙個問題

1 資料庫資料量暴增,對比其他業務類似的資料庫發現某個表的資料量異常,最後確定了乙個重複遷移資料的bug.120301 17 30 43 error column count of mysql.db is wrong.expected 22,found 15.the table is probabl...

mysql公升級 5 1公升級到5 7

一 mysql公升級 1.備份資料庫 mysqldump u root ppasswod all databases data bak db bak date y m d h m sql 同時可備份整個mysql目錄,包括data目錄,可用於公升級失敗快速回滾 2.安裝5.7 提供兩種安裝方式參考,...