MySQL 4.0 進級到mysql 5.0的辦法。本站提示廣大學習愛好者：（MySQL 4.0 進級到mysql 5.0的辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL 4.0 進級到mysql 5.0的辦法正文
1、從 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, DATETIME, 或 TIME 類型的函數的成果會被轉換成時光型
2、再看從 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 中，只能准確的應用前者了，後者則會有成績。這也應當是下面提到的時光類型產生的變更而至。
到此為止，進級根本停止，年夜致檢討了 DECIMAL 類型也沒成績，剩下的就是檢討其他的了。
