MySQL数据库中数据损坏恢复全过程

前几天因为MySQL数据库部分数据损坏原因，我尝试了下恢复数据，之后整理以下文档，供各位参考,以备各位同事以后如有类似问题，可以少走些弯路,尽快解决问题。

环境：Windows2003

数据库:MySQL

损坏数据文件名:function_products

将数据库内容物理文件直接导入到mysql\data下，每只表各3个文件，依次分别为：.frm .myd .myi。首先我第一想到的是去网上搜索，寻找类似的工具，试图通过工具来恢复已损坏的文件，于是我在google上查找，找到一款名为mysqlrecovery的工具，安装后我用其进行恢复，只可惜效果太不理想，几十MB大的数据文件，恢复之后它提示我竟然只有几十KB。我又想到了MySQL下应有自己本身的修复程序等，于是想通过其来进行恢复，心想应不会太差劲吧，在网上查找了资料，提示：由于临时断电，使用kill -9中止MySQL服务进程，或者是MySQL正在高速运转时进行强制备份操作时等，所有的这些都可能会毁坏MySQL的数据文件。如果在被干扰时，服务正在改变文件，文件可能会留下错误的或不一致的状态。因为这样的毁坏有时是不容易被发现的，当你发现这个错误时可能是很久以后的事了。

于是，当你发现这个问题时，也许所有的备份都有同样的错误。我想我现在碰到的问题可能是这个问题，因为备份的数据也是有部分损坏的数据，所以导致不能完全运行， 意识到myisamchk程序对用来检查和修改的MySQL数据文件的访问应该是唯一的。如果MySQL服务正在使用某一文件，并对myisamchk正在检查的文件进行修改，myisamchk会误以为发生了错误，并会试图进行修复--这将导致MySQL服务的崩溃！这样，要避免这种情况的发生，通常我们需要在工作时关闭MySQL服务。作为选择，你也可以暂时关闭服务以制作一个文件的拷贝，然后在这个拷贝上工作。当你做完了以后，重新关闭服务并使用新的文件取代原来的文件(也许你还需要使用期间的变更日志)。

MySQL数据目录不是太难理解的。每一个数据库对应一个子目录，每个子目录中包含了对应于这个数据库中的数据表的文件。每一个数据表对应三个文件，它们和表名相同，但是具有不同的扩展名。tblname.frm文件是表的定义，它保存了表中包含的数据列的内容和类型。tblname.myd文件包含了表中的数据。tblname.myi文件包含了表的索引(例如，它可能包含lookup表以帮助提高对表的主键列的查询)。 要检查一个表的错误，只需要运行myisamchk(在MySQL的bin目录下)并提供文件的位置和表名，或者是表的索引文件名：

% myisamchk /usr/local/mysql/var/dbname/tblname

% myisamchk /usr/local/mysql/var/dbname/tblname.myi

上面的两个命令都可以执行对指定表的检查。要检查数据库中所有的表，可以使用通配符：

% myisamchk /usr/local/mysql/var/dbname/*.myi

要检查所有数据库中的所有表，可以使用两个通配符：

% myisamchk /usr/local/mysql/var/*/*.myi

如果不带任何选项，myisamchk将对表文件执行普通的检查。如果你对一个表有怀疑，但是普通的检查不能发现任何错误，你可以执行更彻底的检查(但是也更慢！)，这需要使用--extend-check选项：

% myisamchk --extend-check /path/to/tblname

对错误的检查是没有破坏性的，这意味着你不必担心执行对你的数据文件的检查会使已经存在的问题变得更糟。另一方面，修复选项，虽然通常也是安全的，但是它对你的数据文件的更改是无法撤消的。因为这个原因，我们强烈推荐你试图修复一个被破坏的表文件时首先做个备份，并确保在制作这个备份之前你的MySQL服务是关闭的。

我在Win2003下通过命令提示符，输入：

注：此为记录我当时操作的全部过程

d:\documents and settings\administrator>c:

c:\>cd MySQL

c:\mysql>cd data

c:\mysql\data>cd hw_entERPrice

c:\mysql\data\hw_enterprice>myisamchk function_products.frm

'myisamchk' 不是内部或外部命令，也不是可运行的程序或批处理文件。

c:\mysql\data\hw_enterprice>cdc:\>cd mysql

c:\mysql>cd bin

注：查看myisamchk的帮助信息

c:\mysql\bin>myisamchk

myisamchk ver 2.6 for win95/win98 at i32

by monty, for your professional use

this software comes with no warranty: see the public for details.

description, check and repair of isam tables.

used without options all tables on the command will be checked for errors

usage: myisamchk [options] tables[.myi]

global options:

-#, --debug=... output debug log. often this is 'd:t:o,filename'

-?, --help display this help and exit.

-o, --set-variable var=option

change the value of a variable. please note that

this option is deprecated; you can set variables

directly with '--variable-name=value'.

-t, --tmpdir=path path for temporary files

-s, --silent only print errors. one can use two -s to make

myisamchk very silent

-v, --verbose print more information. this can be used with

--description and --check. use many -v for more verbosity!

-v, --version print version and exit.

-w, --wait wait if table is locked.

check options (check is the default action for myisamchk):

-c, --check check table for errors

-e, --extend-check check the table very throughly. only use this in

extreme cases as myisamchk should normally be able to

find out if the table is ok even without this switch

-f, --fast check only tables that haven't been closed proPerly

-c, --check-only-changed

check only tables that have changed since last check

-f, --force restart with '-r' if there are any errors in the table.

states will be updated as with '--update-state'

-i, --information print statistics information about table that is checked

-m, --medium-check faster than extend-check, but only finds 99.99% of

all errors. should be good enough for most cases

-u --update-state mark tables as crashed if you find any errors

-t, --read-only don't mark table as checked

repair options (when using '-r' or '-o')

-b, --backup make a backup of the .myd file as 'filename-time.bak'

--correct-checksum correct checksum information for table.

-d, --data-file-length=# max length of data file (when recreating data

file when it's full)

-e, --extend-check try to recover every possible row from the data file

normally this will also find a lot of garbage rows;

don't use this option if you are not totally desperate.

-f, --force overwrite old temporary files.

-k, --keys-used=# tell myisam to update only some specific keys. # is a

bit mask of which keys to use. this can be used to

get faster inserts!

-r, --recover can fix almost anything except unique keys that aren't

unique.

-n, --sort-recover forces recovering with sorting even if the temporary

file would be very big.

-p, --parallel-recover

uses the same technique as '-r' and '-n', but creates

all the keys in parallel, in different threads.

this is alpha code. use at your own risk!

-o, --safe-recover uses old recovery method; slower than '-r' but can

handle a couple of cases where '-r' reports that it

can't fix the data file.

--character-sets-dir=...

directory where character sets are

--set-character-set=name

change the character set used by the index

-q, --quick faster repair by not modifying the data file.

one can give a second '-q' to force myisamchk to

modify the original datafile in case of duplicate keys

-u, --unpack unpack file packed with myisampack.

other actions:

-a, --analyze analyze distribution of keys. will make some joins in

MySQL faster. you can check the calculated distribution

by using '--description --verbose table_name'.

-d, --description prints some information about table.

-a, --set-auto-increment[=value]

force auto_increment to start at this or higher value

if no value is given, then sets the next auto_increment

value to the highest used value for the auto key + 1.

-s, --sort-index sort index blocks. this speeds up 'read-next' in

applications

-r, --sort-records=#

sort records according to an index. this makes your

data much more localized and may speed up things

c:\mysql\bin>myisamchk c:\mysql\data\hw_enterprice\function_products.frm

myisamchk: error: 'c:\mysql\data\hw_enterprice\function_products.frm' is not a m

yisam-table

c:\mysql\bin>myisamchk c:\mysql\data\hw_enterprice\function_products.myi

checking myisam file: c:\mysql\data\hw_enterprice\function_products.myi

data records: 85207 deleted blocks: 39

myisamchk: warning: table is marked as crashed

myisamchk: warning: 1 clients is using or hasn't closed the table properly

- check file-size

- check key delete-chain

- check record delete-chain

myisamchk: error: record delete-link-chain corrupted

- check index reference

- check data record references index: 1

- check data record references index: 2

- check data record references index: 3

- check record links

myisamchk: error: wrong bytesec: 0-195-171 at linkstart: 841908

myisam-table 'c:\MySQL\data\hw_enterprice\function_products.myi' is corrupted

fix it using switch "-r" or "-o"

继续进行操作：

c:\MySQL\bin>myisamchk --recover --quick c:\MySQL\data\hw_enterprice\function_p

roducts.myi

- check key delete-chain

- check record delete-chain

myisamchk: error: record delete-link-chain corrupted

myisamchk: error: quick-recover aborted; run recovery without switch 'q'

updating myisam file: c:\MySQL\data\hw_enterprice\function_products.myi

myisam-table 'c:\MySQL\data\hw_enterprice\function_products.myi' is not fixed be

cause of errors

try fixing it by using the --safe-recover (-o) or the --force (-f) option

系统提示我使用--safe-recover (-o) or the --force (-f) option进行修复操作，于是

c:\MySQL\bin>myisamchk --safe-recover c:\MySQL\data\hw_enterprice\function_prod

ucts.myi

- recovering (with keycache) myisam-table 'c:\MySQL\data\hw_enterprice\function_

products.myi'

data records: 85207

wrong bytesec: 0-195-171 at 841908; skipped

data records: 85215

将修复后的物理文件复制到mysql\data下之后，通过PHPmyadmin进行访问，正常！本次数据修复操作成功，数据已被正常恢复，总计85215条记录，其中恢复数据共计85207条。

总结本次经验及查找资料，如下：

当你试图修复一个被破坏的表的问题时，有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立，删除信息所指出的文件并再试一次--这通常是上一次修复操作遗留下来的。

这三种修复方法如下所示：

% myisamchk --recover --quick /path/to/tblname

% myisamchk --recover /path/to/tblname

% myisamchk --safe-recover /path/to/tblname

第一种是最快的，用来修复最普通的问题；而最后一种是最慢的，用来修复一些其它方法所不能修复的问题。

如果上面的方法无法修复一个被损坏的表，在你放弃之前，你还可以试试下面这两个技巧：

如果你怀疑表的索引文件(*.myi)发生了不可修复的错误，甚至是丢失了这个文件，你可以使用数据文件(*.myd)和数据格式文件(*.frm)重新生成它。首先制作一个数据文件(tblname.myd)的拷贝。重启你的MySQL服务并连接到这个服务上，使用下面的命令删除表的内容：

MySQL> delete from tblname;

在删除表的内容的同时，会建立一个新的索引文件。退出登录并重新关闭服务，然后用你刚才保存的数据文件(tblname.myd)覆盖新的(空)数据文件。最后，使用myisamchk执行标准的修复(上面的第二种方法)，根据表的数据的内容和表的格式文件重新生成索引数据。

如果你的表的格式文件(tblname.frm)丢失了或者是发生了不可修复的错误，但是你清楚如何使用相应的create table语句来重新生成这张表，你可以重新生成一个新的.frm文件并和你的数据文件和索引文件(如果索引文件有问题，使用上面的方法重建一个新的)一起使用。首先制作一个数据和索引文件的拷贝，然后删除原来的文件(删除数据目录下有关这个表的所有记录)。

启动MySQL服务并使用当初的create table文件建立一个新的表。新的.frm文件应该可以正常工作了，但是最好你还是执行一下标准的修复(上面的第二种方法)。

如果有类似问题，建议自己先分析问题根源，查找资料，自己动手解决，不但可以多学更多知识技巧，更重要的是，自己也在解决问题的同时得到了快乐。