MySQL 5.0 – > 5.1升级，桌面升级需要很长时间

我们有一个在Debian etch（！）上运行MySQL 5.0的数据库服务器，并决定升级。 现在它在Debian上运行5.1。

该数据库服务器在SATA RAIDarrays上有大约1.2TB的MyISAM数据，以及2GB的RAM。 通常速度不是这个服务器运行的查询的一个因素，它主要是背景的东西。

升级时，Debian软件包会运行一个维护脚本来升级表，但升级每个表需要很长时间。 我的意思是说，每张桌子大约需要18个小时，而按照现在的速度，这个地段要花费6个星期的时间。 这是一个相当大的问题。

我试图增加全球key_buffer到512MB，这似乎是符合build议，没有任何效果。

• 针对MySQL的HA设置/主要是MyISAM表
• 如何logging所有等待表锁的MySQL查询？
• MyISAM和InnoDB如何利用HD空间？
• 如何知道数据库使用的存储引擎？
• 当与MyISAM混合时，InnoDB表在mysqldump过程中被locking了吗？

这个问题似乎是它使用“修复与键caching”的方法，这比sorting方法慢得多：

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开始的。 我已经通过设置全局variables来纠正这个问题，但debian脚本的会话仍然可能使用一些较小的值吗？ 如果有，我可以改变它吗？

 mysql> SET SESSION key_buffer_size = ... ;