升级 MySQL

周二, 2006/07/18 - 09:04 — yejr

1、概述

通常，从一个发布版本升级到另一个版本时，我们建议按照顺序来升级版本。例如，想要升级 MySQL 3.23 时，先升级到 MySQL 4.0，而不是直接升级到 MySQL 4.1 或 MySQL 5.0。

以下是在升级 MySQL 时需要注意的事项：

仔细阅读一下升级的目标版本的新特性和改变的特性，以及2个版本之间的不同特性
升级前一定要备份所有的数据
如果是在Windows平台上升级MySQL，请阅读附录 "在Windows平台上升级MySQL"
有些不同版本间的升级可能会涉及对授权表的修改，请尤其注意这个问题，详情请阅读附录 "升级授权表"
如果正在运行着同步，请阅读附录 "升级同步"
如果之前运行着MySQL-Max发布版本，想要升级到非MySQL-Max发布版本时，就需要从 mysqld_safe 去掉启动 mysqld-max 服务器的参数

在同一个发布系列版本的MySQL间，可以随意拷贝格式文件和数据文件。如果在MySQL运行过程中改变了字符集，就需要对每个MyISAM表执行 "myisamchk -r -q --set-character-set=charset" 命令修复一下。否则的话，索引的排序可能不正确，因为修改了字符集，就可能会改变索引的顺序。

通常情况下，升级到新版本不需要修改任何数据表。请检查MySQL发布事项中提到的升级需要注意的地方，如果发现不能直接升级的话，就先用 mysqldump 将数据导出来，然后再导回去。

如果担心升级失败，就先把旧版本的MySQL改个名字备份起来，以备所需。

同时，升级完之后可能还需要重新编译跟MySQL相关的程序，因为新版本的头文件和库文件可能有改变了。

如果升级后发生问题了，请先检查是否使用了旧的my.cnf配置文件，可以通过执行命令 "mysqld --print-defaults" 来打印出各种配置信息来确认。

升级的时候最好也升级类似Perl的 DBD::mysql 模块，同样，对PHP和Python而言也是一样。

2、从 MySQL 5.0 升级到 MySQL 5.1

从 5.0 升级到 5.1 的时候，必须要升级授权表。否则，可能某些存储过程无法运行。详情请看附录 "mysql_update MySQL升级时检查数据表"。

以下是从 5.0 升级到 5.1 需要注意的事项：

检查所有的变化，尤其注意那些标志为 "不兼容的变化" 的部分。详情请看附录 "mysql_update MySQL升级时检查数据表"
可能某些发布版本会改变授权表的机制
查看所有重大的变化，详情请看MySQL手册的 "D.1.1.?Changes in release 5.1.10 (Not yet released)" 章节

以下是升级到MySQL 5.1之后会发生的一些变化：

服务器部分：

不兼容的变化：MySQL 5.1 实现了支持无需重启服务器就能在运行时加载或卸载API插件。这个特性需要用到mysql.plugin表，可以运行 "mysql_upgrade" 命令来创建该表

插件安装在系统变量 plugin_dir 所指的目录下。这个变量也控制着用户自定义函数(UDFs)所在目录，这相对以前的版本有所改变。在MySQL 5.1中，所有的UDFs库必须都安装到 plugin_dir 目录下，从旧版本升级的时候，必须把那些库文件都移动到这个目录下
不兼容的变化：系统变量 table_cache 改名为 table_open_cache
不兼容的变化：在MySQL 5.1.6 中 FULLTEXT 的索引结构发生变化了。当升级到 5.1.6 甚至更高之后，需要对每个包含 FULLTEXT 字段的数据表执行 "REPAIR TABLE" 语句
在 MySQL 5.1.6 以前，MySQL把普通的查询日志和慢查询都写到文件中。从5.1.6以后，这些日志可以灵活地选择是是写到日志文件中(跟以前一样)或者写到 mysql 数据库的 general_log 和 slow_log 表中。如果启用日志记录，这2种方式都可以使用。选项 --log-output 用来控制这2种日志的记录方式
从5.1.6开始，特殊字符集的数据库和表的标识符在创建相应目录和文件时都会用对应的字符集编码了

SQL分：

不兼容的变化：在MySQL 5.1.8开始，TYPE = engine_name 还仍然是 ENGINE = engine_name 的同义语法，但有警告。从5.2开始，将完全删除这种语法，并报告错误。
不兼容的变化：在MySQL 5.0.10中，触发器的命名空间已经改变了。在以前，触发器的名字必须和每个数据表都不一样。现在，只需要在数据库内唯一就行了。隐含的变化就是，DROP TRIGGER 语法使用模式名而非数据表名(模式名是可选参数，如果忽略了，就使用当前的模式)
当从5.0升级到5.0.10及更高时，则必须删除触发器后重新创建它们，否则升级后就无法删除触发器了。建议如下：
1. 导出触发器：
```
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;
```
  将触发器导出到文件 "/tmp/triggers.sql" 中去。
2. 停止服务器，然后删除数据库目录下的所有 "TRG" 文件：
```
shell>rm -f */*.TRG
```
3. 启动服务器，倒入触发器：
```
mysql> delimiter // ;
mysql> source /tmp/triggers.sql //
```
不兼容的变化：MySQL 5.1.6引进了触发器权限机制。以前，创建触发器需要有 SUPER 权限，现在，这个操作只需要有 TRIGGER 权限。这改善了权限安全状况
一些MySQL 5.1中作为保留关键字在MySQL 5.0中并没有作为保留关键字
新引入了 "INSTALL PLUGIN" 和 "UNINSTALL PLUGIN" 语句用于操作API插件。同样，创建 FULLTEXT 索引时，可以用 "WITH PARSER" 子句关联解析器插件

3、从 MySQL 4.1 升级到 MySQL 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之后会发生崩溃
不兼容的变化：从5.0.3开始，除非和主函数之间有辅助的符号链接，否则服务器将不再默认地加载用户自定义函数(UDFs)，也可以通过 --allow-suspicious-udfs 选项来启用
不兼容的变化：5.0中禁用了更新日志(update log) ，不过可以用二进制日志(binary log)来代替它
不兼容的变化：5.0中不再支持 ISAM 类型存储引擎(作者：可以通过重新编译源代码支持，不过非常不建议这么做)
不兼容的变化：5.0中不再支持 MyISAM 的 RAID 选项，可以用 mysqldump 导出旧表然后重新导回去实现升级
在5.0.6中，记录存储过程和触发器的二进制日志发生了一些变化，详见手册的 "17.4 Binary Logging of Stored Routines and Triggers"

SQL部分：

不兼容的变化：从5.0.12开始，自然连接和使用 USING 的连接，包括外部连接的衍生形式，都按照SQL:2003标准来处理了；这个变化导致减少了自然连接和使用 USING 的连接产生的结果字段数，并且还将按照更合理的顺序显示这些字段，逗号比较符的优先顺序和 JOIN, LEFT JOIN 中的一样了
不兼容的变化：在以前，等待超时的锁会导致 InnoDB 回滚当前全部事务，从5.0.13开始，就只回滚最近的SQL语句了
不兼容的变化：触发器的变化，跟前面讲到的一样
不兼容的变化：从5.0.15开始，CHAR() 函数返回二进制字符串，而不是按照连接字符集格式的字符串。子句 USING charset_name 可以自定义返回结果的字符集
不兼容的变化：在5.0.13以前，NOW() 和 SYSDATE() 返回的结果一样。但从5.0.13开始，SYSDATE() 返回的是语句执行点的时间，这就可能和 NOW() 返回的结果不一样了，不过可以用 --sysdate-is-now 选项让 SYSDATE() 作为 NOW() 的同名函数
不兼容的变化：在5.0.13以前，GREATEST(x,NULL) 和 LEAST(x,NULL) 如果 x 不是 NULL 值，则返回 x 。从5.0.13开始，只要任何参数是 NULL ，就返回 NULL，跟Oracle一样
不兼容的变化：在4.1.13/5.0.8以前，DATETIME 的加0后就转换成 YYYYMMDDHHMMSS 格式，现在变成 YYYYMMDDHHMMSS.000000 格式了
不兼容的变化：在4.1.12/5.0.6中，语句 LOAD DATA INFILE 和 SELECT ... INTO OUTFILE 中，当 FIELDS TERMINATED BY 和 FIELDS ENCLOSED BY 的值都是空的时候，结果就被改变了。以前，字段都按照它显示的宽度来读写的。现在变成按照足够保存字段值的宽度来读写它。然而，对MySQL 4.0.12/5.0.6来说，那些在它们之前导出来的文件可能无法正确用 LOAD DATA INFILE 语句导入
一些MySQL 5.0中作为保留关键字在MySQL 4.1中并没有作为保留关键字
从5.0.3开始，DECIMAL 用更有效的格式来存储
5.0.3开始，在计算 DECIMAL 值和舍入精确值的时候采用精确数学
4.1中，FLOAT 或 DOUBLE 之间的比较碰巧没问题，但在5.0中可能就不行了
从5.0.3开始，VARCHAR 和 VARBINARY 字段中末尾的空格不再删除
从5.0.3开始，BIT 是一个独立的数据类型了，不再是 TINYINT(1) 的同名词了
MySQL 5.0.2增加了一些SQL模式以使对排除包含非法或者缺失值得记录有着更严格的控制
从5.0.2开始，关键字 SCHEMA 和 SCHEMAS 被认为分别是 DATABASE 和 DATABASES 的同名词
5.0中用户变量对大小写不敏感，而4.1中则不然
增加了一个新的启动选项 innodb_table_locks，它导致 LOCK TABLE 时也可以请求 InnoDB 表锁。这个选项默认打开，不过可能在 AUTOCOMMIT=1 和 LOCK TABLES 应用中会导致死锁

C API部分：

不兼容的变化：由于5.0中 DECIMAL 数据类型的实现方式发生了变化，因此如果使用就版本的库文件需要注意这个问题
不兼容的变化：在5.0.3中，ER_WARN_DATA_TRUNCATED 警告符号改名为 WARN_DATA_TRUNCATED 了
MYSQL 结构体中的 reconnect 标志被 mysql_real_connect() 设为 0。

4、从 MySQL 4.0 升级到 MySQL 4.1

服务器部分：

不兼容的变化：以下好几个都是需要重建数据表的，可以使用 mysqldump 导出表后重新导回去
- 如果在4.1.0到4.1.3版本的MySQL中创建了包含 TIMESTAMP 字段的 InnoDB 表。则在升级到4.1.4及更高时需要重建表，因为存储格式发生变化了
- 从4.1.3开始，InnoDB 表采用同一种字符集比较函数来比较那些非latin1_swedish_ci 字符集且不是 BINARY 的字符串
- 如果在4.1.0到4.1.5版本的MySQl中对 UTF8 字段或者其他多字节字段作了前缀索引，则在升级到4.1.6及更高时必须重建表
- 如果在4.1之前，数据库、表、字段、约束名中使用了重音字符(字节值是128到255的字符)，那么不能直接升级到4.1。因为4.1使用 UTF8 来存储元数据名。
- 字符串根据标准SQL来比较：比较之前不删除末尾的空格，以前用末尾空格扩展了比较短的字符串。现在的结果是 'a' > 'a/t'，以前则不这样。可以用 mysqlcheck 来检查一下数据表
- MyISAM 现在使用更好的校验和算法了
不兼容的变化：MySQL把字符串类型字段的长度定义理解为字符长度而不是字节长度。
重要提示：MySQL 4.1用 UTF8 字符集存储数据表名和字段名。如果有用标准 7字节 US-ASCII 范围之外的字符作为表名/字段名的话，需要重建表
重要提示：升级到4.1.1或更高后，就很难降级回到4.0或4.1了，因为 InnoDB 使用了多个表空间的缘故
不兼容的变化：MySQL 4.1.13支持让每个连接设定时区，因此系统变量 timezone 改成 system_time_zone
所有的数据表和非二进制字符串(CHAR, VARCHAR, 和 TEXT)的字段都有字符集，二进制字符串字段包括 BINARY, VARBINARY, 和 BLOB
MySQL4.0中，如果有字段类型为 CHAR BINARY 或 VARCHAR BINARY，则它们会被当作二进制字符串类型
如果数据表的字段中存储着MySQL 4.1直接就能支持的字符集字符数据时，则可以将这个字段的值转换成由合适的字符集存储
MySQL 4.1中对数据结构描述文件 .frm 的格式稍作改进，新版本能兼容这个新格式，但是旧版本则不能
windows下的服务器启动时增加 --shared-memory 选项即可支持从本地客户端连接时使用共享内存
不兼容的变化：从MySQL 4.1.1开始，对用户自定义函数集合接口发生了很大改进
不兼容的变化：从4.1.10a开始，除非和主函数之间有辅助的链接，否则服务器将不再默认地加载用户自定义函数(UDFs)，也可以通过 --allow-suspicious-udfs 选项来启用

客户端部分：

mysqldump 默认启用 --opt 和 --quote-names 选项

SQL部分：

不兼容的变化：字符串根据标准SQL来比较，如上面的"服务器变化"部分中提到的
不兼容的变化：TIMESTAMP 返回 'YYYY-MM-DD HH:MM:SS' 格式的字符串。在MySQL 4.0中，可以增加选项 --new 来获得MySQL 4.1中这方面的特性
不兼容的变化：二进制数据例如 0xFFDF 被当成字符串而非数字
不兼容的变化：在MySQL 4.1.1前，语句解析器不是那么严格，它在处理字符串转时间转换时会忽略第一个数字前的其他字符。在4.1.1之后，就比较严格了
不兼容的变化：在MySQL 4.1.2，SHOW TABLE STATUS 结果的 Type 字段改名为 Engine 了
当执行多表删除语句时，要删除的表只能使用它的别名，而不能用真实表名
返回结果是 DATE, DATETIME, 或 TIME 类型的函数的结果会被转换成时间型
AUTO_INCREMENT 字段不能设定 默认(DEFAULT) 值了
LIMIT 不再接受负数参数了
SERIALIZE 不再是 sql_mode 变量的有效值了，它的取代值是 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

C API部分：

MySQL 4.1中的密码哈希算法做了改进以提升安全性，不过会导致兼容性问题。使用MySQL 4.0及更早版本的客户端库文件会发生问题。

不兼容的变化：mysql_shutdown() 函数增加一个参数：SHUTDOWN-level
某些函数例如 mysql_real_query() 发生错误时返回 1 而非 -1

密码处理部分：

MySQL 4.1中的密码哈希算法做了改进以提升安全性，不过会导致兼容性问题。使用MySQL 4.0及更早版本的客户端库文件会发生问题。解决办法有：

升级客户端库文件到4.1(不用升级服务器端库文件)
运行 mysql_fix_privilege_tables 脚本来加宽 user 表中的 Password 字段值，以适应新的哈希算法。如果想要允许4.1以下的客户端还能连接到服务器，那么服务器运行时要增加参数 --old-passwords

5、附录

1、) 在Windows平台上升级MySQL步骤：

备份旧数据
停止旧服务器
从windows的系统服务中删掉mysql服务，用如下命令：
```
C:/> C:/mysql/bin/mysqld --remove
```
用可执行安装文件方式安装mysql，或者解压可直接执行的二进制压缩包来安装
重新注册mysql服务，用如下命令：
```
C:/> C:/mysql/bin/mysqld --install  
```
重启服务器
其他的问题详见上面提到的各种升级中会碰到的情况

2、) 升级授权表

升级授权表之前一定要备份好 mysql 数据库，以备升级失败时使用旧的授权表。

在unix或类unix系统中，运行 mysql_fix_privilege_tables 脚本来升级授权表：

shell> mysql_fix_privilege_tables

必须在 mysqld 运行着的时候执行这个脚本，它尝试使用 root 帐号来连接服务器；因此，当 root 需要密码时，用如下方式来指定密码：

shell> mysql_fix_privilege_tables --password=root_password

在 MySQL 4.1之前，则是用如下形式来指定密码：

shell> mysql_fix_privilege_tables root_password

接下来 mysql_fix_privilege_tables 脚本会升级授权表，在这个过程中可能会有一些 Duplicate column name 警告信息，无需理会它们。待它运行完之后，重启一下服务器即可。

在windows平台上，授权表想要升级到4.0.15并不容易。从4.0.15开始，发行版中包含一个sql脚本：mysql_fix_privilege_tables.sql，用 mysql 客户端运行它来升级授权表，运行类似如下命令：

C:/> C:/mysql/bin/mysql -u root -p mysql
mysql> SOURCE C:/mysql/scripts/mysql_fix_privilege_tables.sql

3、) 升级同步

请查看我翻译的文档"6.6 升级同步"

4、) mysql_update MySQL升级时检查数据表

每次升级的时候都必须运行 mysql_upgrade 脚本。它检查了当前版本的MySQL下的所有数据库表的不兼容性，就会检查这些表；并且发现有问题时，也会修复这些表。mysql_update 同时升级了系统表，因此可以兼容新的权限机制并且使用新增的权限。

由于 mysql_update 会把检查过和修复过的表都标记上当前的MySQL版本号，因而保证了下一次在同一个MySQL版本下运行这个脚本时，都会再次报告哪些表需要修复或检查。

它还会把MySQL的版本号记录在数据文件目录下的一个文件中：mysql_upgrade.info。这个文件用于标识当前发布版本检查表时哪些表可以略过，检查时想要忽略这个文件，只需附加上 --force 选项。

为了能检查和修复数据表，并且升级系统表，mysql_update 执行了一下命令：

mysqlcheck --check-upgrade --all-databases --auto-repair
mysql_fix_privilege_tables

mysql_update 目前只支持类unix平台；在windows下，需要手工执行 mysqlcheck 命令，升级授权表请看附录"升级授权表"。

执行 mysql_update 时，MySQL服务器必须运行着，它有以下几个参数：

--help
显示帮助信息并且退出
--basedir=path
设定MySQL的安装路径
--datadir=path
设定MySQL的数据文件路径
--force
告诉 mysql_update，在检查时忽略是否存在 mysql_upgrade.info 文件，强行检查该版本的MySQL数据表，不管是否已经检查过了
--user=user_name, -u user_name
连接到MySQL的用户名，默认是 root
--verbose
冗余模式。发生问题时打印出更多的信息

其他的选项诸如 --password[=password] 是要传递给 mysqlcheck 和 mysql_fix_privilege_tables 脚本的，并不是必须的。

MySQL高级技术

添加新评论

周五, 2006/10/27 - 22:21 — 游客

什么时候mysql才能支持

什么时候mysql才能支持full outer join以及在view 的from 后面可以跟子查询呢？

遇到这两个问题，实在搞不定了，请问大家应该如何解决？还是我应该放弃mysql选择其他数据库呢？

我现在想到的是用union代替full outer join，用视图代替子查询，搞得代码过度膨胀，根本没有可读性了。不知道有没有更“标准”的方法呢？或者哪个版本会支持这个功能？

郁闷啦 :-)

请高手指点一下吧，谢谢啦。

周五, 2006/10/27 - 22:37 — 游客

刚才看了一下PostgreSQL

刚才看了一下PostgreSQL的文档，好像也不支持full outer join :-)
不过人家好像支持子查询:-(

现在来看问题变成了，怎样书写查询语句才能更有可读性啦。

周六, 2006/10/28 - 22:35 — yejr

MySQL

MySQL 5.1新特性中即将加入full outer join;子查询(sub query)在 MySQL 4.1 版本以后就能支持了.视图(view) 在 MySQL 5.0 之后能支持.
SQL 语句的可读性主要是靠编程规范来定义的,通常的规则是每行的语句都不是一个完整的语句,以此避免出现误操作.关键字都大写,数据库/表/字段名用反引号引用起来,例如:

SELECT * FROM `db1`.`tbl1` WHERE
  `filed` = 1
  AND `field` = 2;

MySQL 中文网: http://imysql.cn
Google MySQL 中文用户群：http://groups.google.com/group/imysql

给你的祝福，要让你招架不住！

周五, 2006/09/15 - 16:42 — 游客

如果用mysqldump先从

如果用mysqldump先从旧版mysql数据库导出所有数据，然后再安装新版的mysql 并创建一个空的数据库再用dump的数据导入至新版mysql是不是就可以直接进行跳跃式升级了(3->5)?

周五, 2006/09/15 - 17:42 — yejr

如果没有涉及到一

如果没有涉及到一些不可兼容的问题时，是可以的，比如timestamp字段类型。

欢迎来到MySQL中文网: http://imysql.cn

给你的祝福，要让你招架不住！

升级 MySQL

升级 MySQL

评论

什么时候mysql才能支持

刚才看了一下PostgreSQL

MySQL

如果用mysqldump先从

如果没有涉及到一

你可能感兴趣的:(mysql服务器管理优化)