MySQL 4.0升级到5.0

一、从 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中这方面的特性 在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 表文件

（编辑：济南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!