mysql 4.0 升级到5.0--

《mysql 4.0 升级到5.0--》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

1、MySQL4.0升级到5.0>>　　由于需要，从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返回'

2、YYYY-MM-DDHH:MM:SS'格式的字符串。在MySQL　　4.0中，可以增加选项--neysqldump)MySQL5.0.15开始，如何处理BINARY字段中填充的值已经改变了。填充的值现在是　　0x00而非空格了，并且在取值的时候不会去除末尾的空格从MySQL5.0.3开始，DECIMAL的实现方式已经改变了，5.0对DECIMAL　　的格式限制严格多了在MySQL5.0.3到5.0.5之间版本的MyISAM和InnoDB表中创建的DECIMAL　　字段升级到5.0.6之后会发生崩溃在以前，等待超时的锁会导致InnoDB　　回滚当前全部事务，

3、从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，它导致LOCKTABLE时也可

4、以请求　　InnoDB表锁。这个选项默认打开，不过可能在AUTOMIT=1和LOCKTABLES　　应用中会导致死锁　　看来，我只需主要关注时间(　　TIMESTAMP,DATETIME<DATE,TIME)和　　数值型(　　FLOAD,DOUBLE,DECIMAL)这两种类型的变化；另外，我升级过程中暂时还不需要涉及到字符集问题，因此相对轻松一些。　　升级步骤如下：执行FLUSHTABLESyISAM表文件用　　mysqldump导出Innodb类型的表　　整个过程都很顺利，新系统启动之后，发现如下2个问题：新增了关键字　　INOUT，因此需要检查表结构中

5、还有其他什么字段使用关键字了　　DATE_FORMAT函数要求严谨多了，DATE_FORMAT('2006/11/2409:14:00','%Y-%m-%d%T')　　和DATE_FORMAT('2006/11/2409:14:00','%Y-%m-%d%T')　　的结果完全不一样，在4.0中，能兼容这两种格式，而在5.0中，只能正确的使用前者了，后者则会有问题。这也应该是上面提到的时间类型发生的变化所致。　　到此为止，升级基本结束，大致检查了　　DECIMAL类型也没问题，剩下的就是检查其他的了。>

6、>>>这篇文章来自..，。