问题表现:
以 discuz 论坛的帖子数据表(cdb_posts)为例,该表有 887106 条记录,正常情况下,在一个 P4 2.4G、1G 内存的 PC 机上执行 REPAIR TABLE 的耗时大概 95s,如下:
以 discuz 论坛的帖子数据表(cdb_posts)为例,该表有 887106 条记录,正常情况下,在一个 P4 2.4G、1G 内存的 PC 机上执行 REPAIR TABLE 的耗时大概 95s,如下:
mysql> SHOW GLOBAL VARIABLES LIKE 'myisam_repair_threads';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| myisam_repair_threads | 1 |
+-----------------------+-------+
mysql> REPAIR TABLE cdb_posts;
+-----------------+--------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+-----------------+--------+----------+----------+
| Forum.cdb_posts | repair | status | OK |
+-----------------+--------+----------+----------+
1 row in set (1 min 35.58 sec)
而同等硬件条件下,如果把 myisam_repair_threads 设置成 >1(例如7,设置完之后记得重启 MySQL) 的话,则会有问题,表现为 REPAIR 进程类似发生死锁的状况,一直无法完成,如下:
mysql> SHOW GLOBAL VARIABLES LIKE 'myisam_repair_threads';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| myisam_repair_threads | 2 |
+-----------------------+-------+
mysql> REPAIR TABLE cdb_posts;
再找个终端登录 MySQL,执行 SHOW PROCESSLIST 可以看到如下情况:
mysql> SHOW PROCESSLIST;
....
| 1 | root | localhost | Forum | Query | 1330 | Repair with 7 threads | REPAIR TABLE cdb_posts |
....
最后,google了一下,发现也有其他人报告这个bug,详情请看:
OPTIMIZE TABLE cause race condition in IO CACHE SHARE,号称是在 5.0.40 已经修复了,可是我用的版本是 5.0.45,却依然存在,谁碰到同样的情况请不吝留下言,谢谢 :)
本文出自 “MySQL中文网”博客
http://www.imysql.cn/
本文出自 “老叶茶馆” 博客,转载请与作者联系!