MySQL数据库（20千兆字节的表和索引）已经损坏。 我使用MySQL-admingraphics界面启动了修复选项，现在它已经运行了24小时。 当我检查MyISAM选项（缓冲区，线程等）时，我意识到它们性能极低：1个修复线程，8 Mb的sorting缓冲区…
我的问题是什么更好：停止修复过程，并以更好的configuration再次启动，或保持运行，等待。 有什么方法可以知道修理过程是什么，或者需要多less时间？
您可以通过查看数据目录的内容来跟踪修复进度; 您会看到名称以＃开头的表格，这些表格在维修期间使用。
您还可以选中SHOW PROCESSLIST以确保它没有执行“使用keycache修复”，因为这比“通过sorting修复”
大桌子修理很慢; 你应该避免使用MyISAM非常大的表，特别是有很多索引。 宁愿分割它们，以减less维修时间。 这可能需要对应用程序代码进行重大更改。
基本上是停电，数据库已经损坏。
我不停止维修过程，但似乎需要很长时间。 我希望它能被正确地恢复。 无论如何，我已经跟随了一些未来的迹象：
1.-将以下内容添加到my.conf文件中
[mysqld] myisam-recover=backup,force 有了这个MySQL将强制恢复每次myisam引擎损坏。
2.-增加要修复的线程数量和sorting缓冲区的大小。
3.-不要使用graphics化的mysql-admin界面，使用命令行。 基本上，因为命令行mysqlcheck有一个详细的选项。
当然还有备份:-)
我强烈build议不要停止这个过程。
你在进程列表中看到的1个线程是MySQL的工作方式，如果你把它停在中间，你可以对现有的数据库造成损害。
也许你可以提供更多关于你的数据库发生了什么变化的信息？
嗯…作为十个启动器，您可以通过执行“show processlist”来确认修复正在运行。 从MySQL提示符。
（可能不是你正在寻找的答案，但希望沿着这条路走一步。）
[呃 – 被MarkR殴打]
我的修复是永久的，因为磁盘充满临时文件。 我没有注意到。 我的mysql目录中的servername.err文件包含这样的行….
101104 5:43:24 [错误] / usr / sbin / mysqld：磁盘已满写入'/ tmp / STiktcbP'（错误代码：28）。 等待有人释放空间…在60秒内重试
检查你的php.ini的时间限制，很可能你的脚本在300秒后已经停止运行！ （你也可以做phpinfo（）并检查输出）
你只能通过命令行的mysql界面来修复这么大的数据库。