MySQL 5.0 -> 5.1 升级，表升级耗时很长

Question

我们有一个在 Debian etch (!) 上运行 MySQL 5.0 的数据库服务器，并决定是时候升级了。它现在在 Debian 挤压上运行 5.1。

该数据库服务器在 SATA RAID 阵列上有大约 1.2TB 的 MyISAM 数据和 2GB 的内存。通常速度不是这个服务器运行的查询的一个因素，它主要是后台的东西。

升级时，Debian 软件包运行维护脚本来升级表，但升级每个表需要很长时间。长，我的意思是每张桌子大约需要 18 个小时，而按照目前的速度，做很多事情大约需要 6 周。这是一个相当大的问题。

我试过将全局 key_buffer 增加到 512MB，这似乎符合建议，但没有效果。

问题似乎是它使用了“Repair with keycache”方法，这比 sort 方法慢得多：

mysql> show processlist;
+-----+------------------+----------------------------------+------------------+---------+-------+----------------------+--------------------------------------------------------------------------+
| Id  | User             | Host                             | db               | Command | Time  | State                | Info                                                                     |
+-----+------------------+----------------------------------+------------------+---------+-------+----------------------+--------------------------------------------------------------------------+
|   5 | debian-sys-maint | localhost                        | xxxxxxxxxxxxxxxx | Query   | 45146 | Repair with keycache | REPAIR TABLE `xxxxxxxxxxxxxxxx`.`xxxxxxxxxxxxxxxxxxxx`     

由于需要升级，其他表无法访问：

mysql> check table xxxxxxxxxxxxxxxxxxxx fast quick;
+---------------------------------------+-------+----------+---------------------------------------------------------------------------------------------------+
| Table                                 | Op    | Msg_type | Msg_text                                                                                          |
+---------------------------------------+-------+----------+---------------------------------------------------------------------------------------------------+
| xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | check | error    | Table upgrade required. Please do "REPAIR TABLE `xxxxxxxxxxxxxxxxxxxx`" or dump/reload to fix it! |
+---------------------------------------+-------+----------+---------------------------------------------------------------------------------------------------+
1 row in set (1.09 sec)

主要问题是，如何升级这些表并更快地使数据在线？

次要问题是：

• 将 myisamchk 与“ myisamchk --sort-recover --analyze --sort_buffer_size=256M --key_buffer=256M --read_buffer=2M --write_buffer=2M tablename”之类的东西一起使用是否会升级表（即不使用 keycache 方法）？
• 我可以安全地终止 debian 脚本并使用更有效的方法升级表吗？
• 服务器最初以只有 16M 的 key_buffer_size 启动。我已经通过设置全局变量纠正了这个问题，但是 debian 脚本的会话是否可能仍在使用一些较小的值？如果可以，我可以更改吗？

Answer 1

事实证明，debian 脚本只是标准的 init 脚本，用于检查是否需要升级表，因此杀死它不是问题，因为它只是在 init 上重新运行。

键缓冲区值不是问题，因为我怀疑这是它用来修复表的键缓存方法 - 对于这么多数据来说它太慢了。

一旦我们'set global myisam_max_sort_file_size=21474836480;'重新启动 mysql，它就开始使用更快的排序方法。但随后在另一张桌子上它又回到了 keycache，所以我将其提高到 80G 并再次重新启动。

所有桌子现已升级。