MySQL表不修复

表信息：

Database name: user_motiva Table name: wp_options.frm wp_options.MYD wp_options.MYI wp_options.TMD

当我做一个mysqlcheck -r –all-databases时，即使你让它坐下来，它也会挂在那张桌子上。即使只是支票挂在同一个地方。

有没有办法修复/修复/恢复该表？

我应该使用myisamchk吗？我看到像这样的东西：

 shell> myisamchk --recover City

你甚至不能从phpMyAdmin甚至“USE”访问/查看数据库。在没有它只是悬挂的MySQL。

我的configuration在一个16GB的ram框

  cat /etc/my.cnf [mysqld] default-storage-engine=MyISAM local-infile=0 symbolic-links=0 skip-networking max_connections = 500 max_user_connections = 20 key_buffer = 512M myisam_sort_buffer_size = 64M join_buffer_size = 64M read_buffer_size = 12M sort_buffer_size = 12M read_rnd_buffer_size = 12M table_cache = 2048 thread_cache_size = 16K wait_timeout = 30 connect_timeout = 15 tmp_table_size = 64M max_heap_table_size = 64M max_allowed_packet = 64M max_connect_errors = 10 query_cache_limit = 1M query_cache_size = 64M query_cache_type = 1 low_priority_updates=1 concurrent_insert=ALWAYS log-error=/var/log/mysql/error.log tmpdir=/home/mysqltmp myisam_repair_threads=4 [mysqld_safe] open_files_limit = 8192 log-error=/var/log/mysql/error.log [mysqldump] quick max_allowed_packet = 512M [myisamchk] key_buffer = 64M sort_buffer = 64M read_buffer = 16M write_buffer = 16M

这是因为从killall -9 mysqld崩溃的表，因为它不会关机和重新启动？

编辑：

 root@server [/var/lib/mysql/user_motiva]# myisamchk -e *.MYI Checking MyISAM file: wp_options.MYI Data records: 1827 Deleted blocks: 3 myisamchk: warning: 3 clients are using or haven't closed the table properly - check file-size - check record delete-chain - check key delete-chain - check index reference - check data record references index: 1 - check data record references index: 2 - check records and index references MyISAM-table 'wp_options.MYI' is usable but should be fixed root@server [/var/lib/mysql/user_motiva]# myisamchk --safe-recover wp_options.MYI - recovering (with keycache) MyISAM-table 'wp_options.MYI' Data records: 1827 myisamchk: error: Can't create new tempfile: 'wp_options.TMD' MyISAM-table 'wp_options.MYI' is not fixed because of errors Try fixing it by using the --safe-recover (-o), the --force (-f) option or by not using the --quick (-q) flag root@ns2 [/var/lib/mysql/user_motiva]# myisamchk -o -f wp_options.MYI - recovering (with keycache) MyISAM-table 'wp_options.MYI' Data records: 1827

这是否意味着它现在是固定的？ 如果是这样，我怎么把它移回去？ （这是在一个不同的服务器上完成的）有没有办法让MySQL在主服务器上运行并运行命令来修复所有文件？

mysqlcheck运行一些操作：检查，修复，分析和优化。您目前正在跳转到“修复”（-r），但是确实应该从“检查”开始，以查看发生了什么，并查看是否有任何回应：

 mysqlcheck --check --quick user_motiva wp_options

如果需要密码，添加“-p”（例如，不在configuration文件中）。

如果通过，尝试没有“ – 快”。一旦你确定了问题（如果有的话），应该更容易进行。

顺便说一下，“myisamchk”是检查表的另一种方法。这里的主要区别在于在数据库不运行时使用。要使用哪个取决于您是否需要为了其他数据而继续运行。

这是否意味着它现在是固定的？

不，不是的。你的粘贴输出清楚地表明

 MyISAM-table 'wp_options.MYI' is not fixed because of errors

原因似乎是

 myisamchk: error: Can't create new tempfile: 'wp_options.TMD'

你可以检查你正在执行myisamchk的用户是否具有在数据目录中创build文件的必要权限，如果该文件还没有以“错误的”权限存在，并且文件系统上可以创build文件（即它是没有挂载只读，有错误或已满）。

请注意，您正在修复只包含索引信息的.MYI文件（按给定顺序存储的索引数据库列的副本，以加快search速度）。因此，如果是在修复/挂载数据库时导致问题的索引文件（.MYI），可以考虑简单地将其从数据目录中删除，启动MySQL守护程序并运行REPAIR TABLE wp_options以从数据库中重build索引信息数据文件。

如果数据文件本身（.MYD）受到损坏的影响，则应该首先在.MYD文件上运行myisamchk ， 而不先使用-e选项，因为myisamchk文档显式声明“[不要]使用此选项，除非您绝望。 “

在运行mysqlrepair数据库时，我遇到了完全相同的问题。

问题1是：用户mysql /etc/passwd文件中的groupid错误。与文件/etc/group group中mysql组的groupid不同，请在继续下一步之前检查并更正。

问题2是：在修复运行期间，通常在/var/lib/mysql/database目录中为每个数据库表创build文件* .TMD。这是通过运行修复的：

 rm /var/lib/mysql/*/*.TMD

然后成功运行：

 mysqlrepair -p database

-p提供的密码。如果需要，也请添加-uusername。