最初的意图是让升级到更新的 MySQL 版本变得轻而易举。我们在保持数据格式兼容性方面做了大量工作（包括 .frm 文件和存储引擎中）；当你安装新版本的 MySQL 时，一切都应该“正常工作”。
在很长一段时间里，情况确实如此，直到 MySQL 5.0，我们不得不做一些数据不兼容的更改，例如某些字符的排序方式以及索引中行末空白的存储方式。
为了简化升级过程，我们创建了“mysql_upgrade”程序，该程序应检测可能不兼容的表并根据需要自动转换数据。
完整的数据升级过程始终应像以下步骤一样简单：
- 安装新的 MariaDB / MySQL 版本。
- 启动 mysqld 服务器。
- 运行 mysql_upgrade。
不幸的是，随着时间的推移，出现了一些问题。我们在一位用户最近尝试从 MySQL 5.0 升级大型安装到 MariaDB 时发现了这一点。遇到的问题包括：
- 名称过长的表未转换为新的 5.1 名称格式
- 某些 InnoDB 表出现错误：“Table upgrade required; Please do “REPAIR TABLE `xxx`” or dump/reload to fix it!”（需要升级表；请执行“REPAIR TABLE `xxx`”或导出/导入来修复！）
- 所有 ARCHIVE 表都出现同样的故障
- 某些内部系统表出现一些奇怪的错误消息
所以这位用户的实际升级过程是：
- 安装新的 MariaDB / MySQL 版本。
- 启动 mysqld 服务器
- 运行 mysql_upgrade
- 列出所有升级失败的表。
- 重新安装之前的 MySQL 版本。
- 使用 mysql_dump 导出问题表
- 删除导出的表。
- 再次安装新的 MariaDB / MySQL 版本。
- 加载导出的表。
- 使用“mysql_upgrade –force”测试是否遗漏了什么
我们在 #maria IRC 频道上了解了上述问题，并在 24 小时内解决了所有问题。我们很高兴地宣布，完整的升级过程又回到了简单的三个步骤：安装新版本，启动 mysqld，运行“mysql_upgrade”。
我们还为 mysql_upgrade 和 mysqlcheck（mysql_upgrade 使用）添加了更多选项，以便在出现问题时更容易找出原因。
作为过程的一部分（并记录更改），我们还在知识库中添加了一些新文章，内容关于
从 MySQL 5.0 升级到 MariaDB、mysql_upgrade 和 mysqlcheck。
我们希望上述所有改进将使所有人的升级过程变得更容易、更可靠！