MySQL 4.0 升级到5.0

　　由于需要，从4.0直接升级到5.0，查看了一下changelog，发现主要有以下变化：

　　一、从 4.0 到 4.1 的主要变化

　　表。则在升级到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 的主要变化

　　"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

　　升级步骤如下：

　　直接拷贝 myisam 表文件

　　mysqldump

　　整个过程都很顺利，新系统启动之后，发现如下2个问题：

　　inout

　　date_format

　　和

　　的结果完全不一样，在 4.0 中，能兼容这两种格式，而在 5.0 中，只能正确的使用前者了，后者则会有问题。这也应该是上面提到的时间类型发生的变化所致。

　　到此为止，升级基本结束，大致检查了

　　decimal