MySQL升级：从4.1到5.0

　　提示：在安装任何新版本的软件之前，最好备份一下你的数据。尽管mysql已经最大限度的保证高质量服务，但当你使用软件的测试发布版本时，你还是应该采取备份的方式来保护你的数据。大体来说，在从mysql从4.1升级到5.0时，你需要做得主要包括以下几个步骤：•这部分主要检查稍后建立起的修改列表里的表项，目的是为了查找其中是否存在会影响你的应用程序的表项。这里具体要注意哪些标志着Incompatible change的选项；这些会造成与Mysql早期版本不匹配，并且应该在更新之前引起你的注意。•阅读MySQL 5.0的历史进程，理解你在5.0中能够使用的重要的新特征。可以参阅Section D.1, “Changes in release 5.0.x (Production)”•如果你是在Windows下运行Mysql 服务器，请参阅Section 2.3.15, “Upgrading MySQL on Windows”部分。同时你也应该注意到Windows下的Mysql服务器中有两个是重新命名的，具体可以参阅Section 2.3.9, “Selecting a MySQL Server type”•MySQL 5.0增加了对于存储信息的程序的支持。该项支持需要在你的mysql数据库中的proc数据表。为了生成该文件，你应该运行mysql_fix_privilege_tables脚本，有关该脚本的描述，请参阅Section 2.10.3, “Upgrading the Grant Tables”。•MySQL5.0添加了浏览功能。该项支持需要在mysql数据库中的user和db表格中添加额外的特殊权限列。为了生成这些列，你应该运行mysql_fix_privilege_tables脚本，具体的描述见Section 2.10.3, “Upgrading the Grant Tables”.•如果你使用复制功能，请参阅Section 6.6, “Upgrading a Replication Setup”，该部分主要提供了升级你的复制设置的相关信息。 几个可视化行为已经在MySQL 4.1和MySQL5.0之间被改变，目的是为了保证MySQL和标准SQL的兼容性。这些改变有可能影响你的应用程序。 下面的列项主要描述了有可能影响应用程序的变化，因此你应该在将MySQL更新到版本5.0之前特别注意这些列项。几个变化：•不兼容变化：对于InnoDB和MyISAM表格的TEXT列中的末端空间的索引顺序改变了。从版本5.0.3开始，TEXT索引被看作是末尾的填补空间部分(如同MySQL的数据类型中的char、VARCHAR和TEXT域)。如果你在文本列中有一个索引，那么你应该在其上运行CHECK TABLE命令。如果该检查报错，则需重建索引:如果是一个InnoDB表格，则清除并重新装载该表格，如果它是个MyISAM表格则运行OPTIMIZE TABLE 或者 REPAIR TABLE命令。•不兼容变化：含有DECIMAL 列的MyISAM 和InnoDB表格将会在升级到MySQL 5.0.6后出现损坏。在更新之前，要先将这些表格采用mysqldump进行清除，同时在更新之后重新装载它们。(当在MySQL5.0.6中生成的这些表格在较低版本如MySQL 5.0.3到 5.0.5中使用时，同样的不匹配情况会发生)•不兼容变化：对于MySQL 5.0.3，服务器默认不再加载用户定义的函数除非它们除了主函数符号外至少还有一个辅助标记(例如，xxx_init或者xxx_deinit符号)。该行为可以被--allow-suspicious-udfs选项所忽略。可参阅Section 25.2.3.6, “User-Defined Function Security Precautions”.•不兼容变化：在MySQL 5.0中更新日志将会被删除掉。如果你事先把它激活的话，你实际上激活的是二进制日志。 •不兼容变化：对于ISAM存储机制的支持已经被删除掉。如果你有任何的ISAM表格，你应该在更新之前对其进行转换。例如将一个ISAM表格转化成使用MyISAM存储机制，可使用以下的声明实现： ALTER TABLE tbl_name ENGINE = MyISAM; 你数据库中的其他ISAM表格的处理与此相同。•不兼容变化：在MySQL 5.0中，对于MyISAM表格的RAID选项的支持已被删除。如果你有使用这些选项的表格，你应该在更新之前对其进行转换。一种方法是采取mysqldump命令清除这些表格，编辑dump文件以删除在CREATE TABLE声明中RAID选项，同时重新加载dump文件。另一种方法是使用CREATE TABLE new_tbl ... SELECT raid_tbl声明来制造一个新的RAID表格。然而，该声明中的CREATE TABLE部分必须含有足够的信息来重新生成列和索引的属性，否则列和索引的属性有可能丢失，而不会出现在新表格当中。可参阅Section 13.1.5, “CREATE TABLE Syntax”。•在一个具体的数据库中，对于RAID表格的.MYD文件存储在数据库目录下，而该目录是在名字含有两个16进制位(即00至ff)数值的子目录中的。在对所有使用RAID选项的表格进行转换后，这些RAID-相关的子目录可能依然存在但是是可以被删除的。在证明他们确实是空的之后，可以手工将他们删除。(如果它们非空的话，则说明有一些RAID表格尚未被转换)。•在MySQL 5.0.6中，存储例程和触发器的二进制日志已经发生了变化。这个变化主要涉及到安全，复制，数据恢复，有关这方面的讨论请见Section 18.4, “Binary Logging of Stored Routines and Triggers”. 。SQL 的变化：•不兼容变化：在MySQL 5.0.10对于触发器的命名空间已经改变。以前的版本中，每个表格中，触发器的名字是唯一的。现在对于schema(数据库)必须是唯一的。这种改变的潜在原因是DROP TRIGGER语法现在使用schema名字而不是表格名(schema在可忽略的情况下是被选择的，即当前的schema将会被使用)。当从以前的版本MySQL 5更新到MySQL5.0.10或者更新的版本时，你必须删除所有的触发器并且重新生成他们，否则的话，在更新之后，DROP TRIGGER将不会起作用。为了实现这个目的，我们特别提供了以下参考步骤：1 将MySQL版本升级至5.0.10以能够访问INFORMATION_SCHEMA.TRIGGERS表格中的触发器信息(它应该对于5.0.10以前版本的触发器同样有效。)2 使用下面的SELECT声明来删除所有的触发器定义SELECT CONCAT('CREATE TRIGGER ', t.TRIGGER_SCHEMA, '.', t.TRIGGER_NAME,' ', t.ACTION_TIMING, ' ', t.EVENT_MANIPULATION , ' ON ', t.EVENT_OBJECT_SCHEMA, '.', t.EVENT_OBJECT_TABLE' FOR EACH ROW ', t.ACTION_STATEMENT, '//' )INTO OUTFILE '/tmp/triggers.sql'FROM INFORMATION_SCHEMA.TRIGGERS AS t; 该声明使用INTO OUTFILE，所以你必须拥有FILE权限。该文件将会被在服务器主机上生成；可以根据你的喜好，来选择一个不同的文件名。为了绝对的安全，检查triggers.sql文件中的触发器定义，如果必要的话，对该文件进行一下备份。１停止服务器同时通过删除你数据库目录中所有的.TRG文件来删除所有的触发器。改变当前路径到你数据库的目录下，同时输入命令如下： shell> rm */*.TRG２启动服务器，同时使用triggers.sql文件重新生成所有的触发器。在本例子当中，命令如下：

1.mysql> delimiter // ; 2.mysql> source /tmp/triggers.sql // ３使用SHOW TRIGGERS声明来检查是否所有的触发器成功生成。 •不兼容变化：对于MySQL 5.0.15, CHAR()函数返回一个二进制字符串而不是一套连接字符集中的字符串。而一个可供选择的USING charset语句句有可能被用来生成一个具体的字符集。同时，比256字符长的变量有可能被用来生成一个单一的字符集。这些改变有可能造成不匹配。

o CHAR(ORD('A')) = 'a' is no longer true: omysql> SELECT CHAR(ORD('A')) = 'a'; o ---------------------- o| CHAR(ORD('A')) = 'a' | o ---------------------- o| 0 | o ---------------------- 为了进行比较，你可以通过增加一个USING语句或者对结果进行转化在非二进制字符集中生成一个结果字符串。

mysql> SELEC CHAR(ORD('A') USING latin1) = 'a'; ----------------------------------- | CHAR(ORD('A') USING latin1) = 'a' | ----------------------------------- | 1 | ----------------------------------- mysql> SELECT CONVERT(CHAR(ORD('A')) USING latin1) = 'a'; -------------------------------------------- | CONVERT(CHAR(ORD('A')) USING latin1) = 'a' | -------------------------------------------- | 1 | -------------------------------------------- oCREATE TABLE … SELECT CHAR(…)生成了VARBINARY列而不是VARCHAR列。为了生成VARCHAR列，使用USING 或者 CONVERT()来将CHAR()转换成如同刚才描述的非二进制字符集。o在以前的版本中，下面的声明将0x00410041('AA'作为ucs2字符串)插入到表格中,而对于MySQL 5.0.15，声明采取0x414值来插入一个ucs2字符。oCREATE TABLE t (ucs2_column CHAR(2) CHARACTER SET ucs2);oINSERT INTO t VALUES (CHAR(0x41,0x41));•不兼容变化:从MySQL 5.0.12开始，自然连接和使用USING命令的连接包括外部连接变量，通过SQL:2003标准来进行处理的。这个改变包括对NATURAL和使用USING语句的连接去除多余的输出列，同时规范输出列表的次序。现在逗号操作符的优先级仍然低于JOIN。•小数点数列以一种更为有效的格式进行存储。为了将一个表格转换为使用新的DECIMAL(浮点数)类型，你应该在它上面执行一个ALTER TABLE命令。ALTER TABLE命令也改变了表格的VARCHAR列以能够使用新的VARCHAR列类型。对于和原有的应用程序可能不匹配的信息，可查阅Chapter 22, Precision Math•MySQL 5.0.3及更高的版本在计算点数值时使用数字精度集(64位浮点数)同时回绕精确的数字。可参见Chapter 22, Precision Math•对于MySQL 5.0.3，结尾空间将不再被从VARCHAR和VARBINARY列中移除，在MySQL 5.0.3和后续版本，对于VARCHAR 和VARBINARY列的最大长度是65,535字符和65,535字节。注意:如果你在MySQL 5.0.3或者后续版本中，你生成了含有新的VARCHAR或者r VARBINARY列的表，那这些表格将在低于MySQL 5.0.3版本中不起作用。在降级之前将这些表格清除掉，同时在降级之后对其进行重载。•对于MySQL 5.0.3，BIT是一个单独的数据类型，而不是TINYINT(1)的同义。可参阅Section 11.1.1, “Overview of Numeric Types”•MySQL 5.0.2添加了几个用于更加严格控制丢弃含有不合法或者丢失数值的记录。可参阅Section 5.3.2, “The Server SQL Mode”. 和Section 1.8.6.2, “Constraints on Invalid Data”。如果你想激活这项控制但同时继续使用存储的不正确日期，例如'2004-02-31'，你应该采取--sql_mode=TRADITIONAL,ALLOW_INVALID_DATES启动服务器。•对于MySQL 5.0.2，SCHEMA和SCHEMAS关键字被分别当作DATABASE和DATABASES同义字所接受。(然而“schemata”是语法正确的，同时有可能出现在MySQL 5.0的系统数据库和数据表格名字中，因此它能够被作为一个输出的关键字使用)•在MySQL 5.0，用户变量是不区分大小写的。在MySQL 4.1中，SET @x = 0; SET @X = 1; SELECT @x;生成两个变量同时返回0.而在MySQL 5.0，该命令生成一个变量同时返回1.•一个名字为innodb_table_locks启动选择项被添加了进来，该选项可能导致LOCK TABLE同时也需要InnoDB表格锁。该选项默认是被激活的。这有可能导致使用AUTOCOMMIT=1和 LOCK TABLES的应用程序死锁。如果你的应用程序在升级之后遇到死锁的情况，你可能需要添加innodb_table_locks=0到你的my.cnf文件。C API 改变: • 因为MySQL 5.0服务器有对小数类型的数据有一种新的执行功能，如果该服务器被一些仍由MySQL4.1版本的客户程序库链接而成的老版本客户程序所使用，就会出现一个问题，如果一个客户使用二进制客户机程序／服务器协议来执行准备好的能产生数值结果的声明，就会出现错误提示：错误发生的原因是4.1版本客户程序库并不支持在5.0版本中增加的新MYSQL_TYPE_NEWDECIMAL类型。而服务器这端，却没有屏蔽这种新的小数数据类型的途径。你可以通过和来自MySQL 5.0的客户端库的应用程序进行重链接来避免这个问题。• MYSQL结构中的再连接标志可以通过mysql_real_connect()设置为0。而只有那些在进行mysql_real_connect()以后没有明确的把标志设为0或1的客户端程序才会发生变化。默认情况下自动重新连接是被认为是危险的（主要是由于表格锁，临时表格，用户变量以及会话变量在重新连接后有可能被丢失）。