通常，从一个发布版本升级到另一个版本时，我们建议按照顺序来升级版本。例如，想要升级 MySQL 3.23 时，先升级到
MySQL 4.0，而不是直接升级到 MySQL 4.1 或 MySQL 5.0。
如果都是比较新的版本的升级可以参考下面的文章，
MySQL数据库的版本更新很快，新的特性也随之不断的更新，更主要的是解决了很多影响我们应用的BUG，为了让我们的MySQL变得更美好，我们有必要去给它升级，尽管你会说它现在已经跑得很好很稳定完全够用了。下面我们来看看几种常用的升级方法。
介绍之前，我们先做一些声明，MySQL采用二进制包来安装，升级都是在同一台DB Server上操作。
第一种，很简单，适用于任何存储引擎。
1. 下载并安装好新版本的MySQL数据库，并将其端口改为3307（避免和旧版本的3306冲突），启动服务。
2. 在新版本下创建同名数据库。
# mysqldump -p3307 -uroot create mysqlsystems_com
3. 在旧版本下备份该数据库。
# mysqldump -p3306 -uroot mysqlsystems_com > mysqlsystems_com.bk
Note: 你也可以加上–opt选项，这样可以使用优化方式将你的数据库导出，减少未知的问题。
4. 将导出的数据库备份导入到新版本的MySQL数据库中。
# mysql -p3307 -uroot mysqlsystems_com < mysqlsystems_com.bk
5. 再将旧版本数据库中的data目录下的mysql数据库全部覆盖到新版本中。
# cp -R /opt/mysql-5.1/data/mysql /opt/mysql-5.4/data
Note: 大家也都知道这个默认数据库的重要性。
6. 在新版下执行mysql_upgrade命令，其实这个命令包含一下三个命令：
# mysqlcheck –check-upgrade –all-databases –auto-repair
# mysql_fix_privilege_tables
# mysqlcheck –all-databases –check-upgrade –fix-db-names
–fix-table-names
Note: 在每一次的升级过程中，mysql_upgrade这个命令我们都应该去执行，它通过mysqlcheck命令帮我们去检查表是否兼容新版本的数据库同时作出修复，还有个很重要的作用就是使用mysql_fix_privilege_tables命令去升级权限表。
7. 关闭旧版本，将新版的数据库的使用端口改为3306，重新启动新版本MySQL数据库。到此，一个简单环境下的数据库升级就结束了。
第二种，同样适用任何存储引擎。
1. 同样先安装好新版本的MySQL。
2. 在旧版本中，备份数据库。
# mkdir /opt/mysqlsystems_bk ; mysqldump -p3306 -uroot –tab=/opt/mysqlsystems_bk mysqlsystems_com
Note: –tab选项可以在备份目录mysqlsystems_bk下生成后缀为*.sql和*.txt的两类文件；其中，.sql保存了创建表的SQL语句而.txt保存着原始数据。
3. 接下来在新版本的数据库下更新数据。
# mysqladmin -p3307 -uroot create mysqlsystems_com
# cat /opt/mysqlsystems_bk*.TRG
启动服务器，倒入触发器：
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 脚本的，并不是必须的。
原文地址：http://www.cnblogs.com/lonelyxmas/p/3790748.html
