MySQL工具系列之myisamchk进行表的维护和崩溃恢复
作者：阿炯
2010-09-01 12:53 - 最后更新 2010-09-02 10:42
1.为了检查/修复MyISAM表(.MYI和.MYD)，你应该使用myisamchk实用程序。为了检查/修复ISA
M表(.ISM和.ISD)，你应该使用isamchk实用程序。
在下文中，我们将讨论myisamchk，但是也适用于老的isamchk。
你可以使用myisamchk实用程序来获得有关你的数据库表的信息、检查和修复他们或优化他们。
下列小节描述如何调用myisamchk(包括它的选项的描述)，如何建立一个表维护的时间表，并且
如何使用myisamchk执行其各种功能。
如果你用--skip-locking运行mysqld(它在一些系统上是缺省的，如Linux)，当mysqld正在使用同
一个表时，你不能可靠地使用
myisamchk检查一张表。如果你能肯定在你运行myisamchk时没有人通过mysqld正在存取表，在
你开始检查表之前，你仅需做 mysqladmin
flush-tables。如果你不能保证，那么当你检查表时，你必须停掉mysqld。如果你在mysqld正在
更新表时运行myisamchk，你可能得到一个表已破坏的警告，即使它没有。
如果你没使用--skip-locking，你能在任何时间使用myisamchk检查表。当你这样时，所有试图更
新表的客户在继续前将等到myisamchk就绪。
如果你使用myisamchk修复或优化表，你必须总是保证mysqld服务器不在使用表(如果你正在使
用--skip-locking，这也适用)。如果你不停掉mysqld，在你运行myisamchk前，你至少应该做一
个mysqladmin flush-tables。
在大多数情况下，你也可使用命令OPTIMIZE
TABLES优化并修复表，但是这不如myisamchk快或可靠(在真正的致命错误的情况下)。在另一方
面，OPTIMIZE TABLE较易使用并且你不必须关心清空表。见7.9OPTIMIZE TABLE句法。
1.1.1 myisamchk调用语法
myisamchk这样调用：
shell> myisamchk [options] tbl_name
options 指定你想要myisamchk做什么。他们在下面描述。(你也可以通过调用myisamchk
--help得到一张选项表。)
没有选项，myisamchk简单地检查你的表。为了得到更多的信息或告诉myisamchk执行校正操作
，指定在下面和下小节描述的选项择。
tbl_name
是你想要检查的数据库表。如果你不在数据库目录的某处运行myisamchk，你必须指定到文件的
路径，因为myisamchk不知道你的数据库位于哪儿。实际上，myisamchk别在乎你正在操作的文
件是否位于一个数据库目录；你可以拷贝对应于一张数据库表的文件到别处并且在那里执行恢复
操作。
如果你愿意，你可以myisamchk命令行命名几个表。你也能指定一个名字作为一个索引文件(用
.MYI后缀)，它允许你通过使用模式*.MYI指定在一个目录所有的表。例如，如果你在一个数据库
目录，你可以这样在目录下检查所有的表：
1 / 21
MySQL工具系列之myisamchk进行表的维护和崩溃恢复
作者：阿炯
2010-09-01 12:53 - 最后更新 2010-09-02 10:42
shell> myisamchk *.MYI
如果你不在数据库目录下，你可通过指定到目录的路径检查所有在那里的表：
shell> myisamchk /path/to/database_dir/*.MYI
你甚至可以通过为MySQL数据目录的路径指定一个通配符来检查所有的数据库中的所有表：
shell> myisamchk /path/to/datadir/*/*.MYI
myisamchk支持下列选项：
-a, --analyze
分析键值的分布。这通过让联结优化器更好地选择表应该以什么次序联结和应该使用哪个键来改
进联结性能。
-#, --debug=debug_options
输出调试记录文件。debug_options字符串经常是d:t:o,filename。
-d, --description
打印出关于表的一些信息。
-e, --extend-check
非常彻底地检查表。这仅在极端情况下是必要的。通常，myisamchk应该找出所有错误，即使没
有改选项。
-f, --force
覆盖老的临时文件。如果你在检查表时使用-f
(运行myisamchk没有-r)，myisamchk在检查期间将自动为出现一个错误的表用-r重启。
--help
显示一条帮助消息并且退出。
-i, --information
打印有关被检查的表的信息统计。
-k #, --keys-used=#
与-r一起使用。告诉ISAM表处理器仅更新头#个索引。较高编号的索引被撤销。这能用来使插入
变得更快！撤销的索引能通过使用myisamchk -r被重新激活。
-l, --no-symlinks
在修复时，不跟随符号连接。通常myisamchk修复一个符号连接所指的表。
-q, --quick
与-r一起使用使得一个修复更快。通常，原来的数据文件没被接触；你能指定第二个-q强制使用
原来的数据文件。
-r, --recover
恢复模式。可以修复几乎所有一切，除非唯一的键不是唯一。
-o, --safe-recover
恢复模式。使用一个老的恢复方法；这比-r慢些，但是能处理一-r不能处理的情况。
-O var=option, --set-variable var=option
设置一个变量的值。可能的变量列在下面。
-s, --silent
沉默模式。当错误发生时，仅写输出。你能使用-s两次(-ss)非常沉默地做myisamchk。
-S, --sort-index
以从高到低的顺序排序索引树块。这将优化搜寻并且将使按键值的表扫描更快。
-R index_num, --sort-records=index_num
2 / 21
MySQL工具系列之myisamchk进行表的维护和崩溃恢复
作者：阿炯
2010-09-01 12:53 - 最后更新 2010-09-02 10:42
根据一个索引排序记录。这使你的数据更局部化并且可以加快在该键上的SELECT和ORDER
BY的范围搜索。(第一次做排序可能很慢！) 为了找出一张表的索引编号，使用SHOW
INDEX，它以myisamchk看见他们的相同顺序显示一张表的索引。索引从1开始编号。
-u, --unpack
解开一个用myisampack压缩的表。
-v, --verbose
冗长模式。打印更多的信息。这能与-d和-e一起使用。为了更冗长，使用-v多次(-vv, -vvv)！
-V, --version
打印myisamchk版本并退出。
-w, --wait
如果表被锁定，等待。
对--set-variable(-O)选项，可能的变量是：
key_buffer_size 当前值: 16776192
read_buffer_size 当前值: 262136
write_buffer_size 当前值: 262136
sort_buffer_size 当前值: 2097144
sort_key_blocks 当前值: 16
decode_bits 当前值: 9
1.1.2 myisamchk内存使用
当你运行myisamchk时，内存分配很重要。myisamchk使用不超过你用-O选项指定的内存量。如
果你想在很大的文件上使用myisamchk，你首先应该确定你想要它使用多少内存。缺省仅使用大
约 3M
来修复。通过使用更大的值，你能使myisamchk更快地操作。例如，如果你有多于32M内存，你
能使用例如这些选项(除了任何你可能指定的选项)：
shell> myisamchk -O sort=16M -O key=16M -O read=1M -O write=1M ...
使用-O sort=16M应该可能对大多数情形就足够了。
必须明白，myisamchk使用在TMPDIR里面的临时文件。如果TMPDIR指向一个内存文件系统，你
可能很容易得到内存溢出的错误。如果它发生，设定TMPDIR指向有更多空间的某个目录并且重
启myisamchk。
1.2 建立一个数据库表维护规范
在一个定期基础而非等到问题出现才实施数据库表的检查是一个好主意。为维护目的，你能使用
myisamchk -s检查。-s选项使myisamchk以沉默模式运行，当错误出现时，仅仅打印消息。
在服务器启动时检查表是一个好主意。例如，无论何时机器在更新当中重新启动了，你通常需要
检查所有可能被影响了的表。(这是一个期望破坏了的表)
如果重启后有一个旧的.pid(进程ID)，你能为safe_mysqld加入一个测试，运行myisamchk检查所
有在过去24小时修改过的表)。(.pid文件在mysqld启动时由它创建，并它正常终止时删除。在系
统启动时存在一个.pid文件表明mysqld异常地终止了)。一个更好的测试将是检查任何表，它的最
后修改时间是比.pid文件更新。
你也应该定期在正常系统操作期间检查表。在TcX，我们运行一个cron任务，每周一次检查我们
3 / 21
MySQL工具系列之myisamchk进行表的维护和崩溃恢复
作者：阿炯
2010-09-01 12:53 - 最后更新 2010-09-02 10:42
所有重要的表，在一个crontab文件中使用这样的行：
35 0 * * 0 /path/to/myisamchk -s /path/to/datadir/*/*.MYI
这打印出损坏的表的信息，因此我们能检验并且在需要时修复他们。当我们现在几年(这确实是真
的)都没有任何意外损坏的表时(由于除硬件故障外的其他原因造成损坏的表)，每周一次对我们是
足够了。
我们建议现在开始，你对所有最后24小时内被更新了表每晚都执行myisamchk
-s，直到你变得象我们那样信任MySQL。
1.3 获得关于一个表的信息
为了获得关于一个表的描述或统计，使用显示在下面的命令。我们以后更详细地解释某些信息。
myisamchk -d tbl_name
以描述模式运行myisamchk，生成你的表的描述。如果你用--skip-locking选项启动MySQL服务器
，myisamchk可以当它运行时报告被一个更新的表的错误。然而，既然在描述模式中myisamchk
不改变表，没有破坏数据的任何风险。
myisamchk -d -v tbl_name
为了生成更多关于myisamchk正在做什么的信息，加上-v告诉它以冗长模式运行。
myisamchk -eis tbl_name
仅显示一个表最重要的信息。因为必须读取整个表，它很慢。
myisamchk -eiv tbl_name
这类似-eis，只是告诉你正在做什么。
myisamchk -d输出的例子：
MyISAM file: company.MYI
Record format: Fixed length
Data records: 1403698 Deleted blocks: 0
Recordlength: 226
table description:
Key Start Len Index Type
1 2 8 unique double
2 15 10 multip. text packed stripped
3 219 8 multip. double
4 63 10 multip. text packed stripped
5 167 2 multip. unsigned short
6 177 4 multip. unsigned long
7 155 4 multip. text
8 138 4 multip. unsigned long
9 177 4 multip. unsigned long
193 1 text
myisamchk -d -v输出的例子：
MyISAM file: company
Record format: Fixed length
File-version: 1
4 / 21
MySQL工具系列之myisamchk进行表的维护和崩溃恢复
作者：阿炯
2010-09-01 12:53 - 最后更新 2010-09-02 10:42
Creation time: 1999-10-30 12:12:51
Recover time: 1999-10-31 19:13:01
Status: checked
Data records: 1403698 Deleted blocks: 0
Datafile parts: 1403698 Deleted data: 0
Datafilepointer (bytes): 3 Keyfile pointer (bytes): 3
Max datafile length: 3791650815 Max keyfile length: 4294967294
Recordlength: 226
table description:
Key Start Len Index Type Rec/key Root Blocksize
1 2 8 unique double 1 15845376 1024
2 15 10 multip. text packed stripped 2 25062400 1024
3 219 8 multip. double 73 40907776 1024
4 63 10 multip. text packed stripped 5 48097280 1024
5 167 2 multip. unsigned short 4840 55200768 1024
6 177 4 multip. unsigned long 1346 65145856 1024
7 155 4 multip. text 4995 75090944 1024
8 138 4 multip. unsigned long 87 85036032 1024
9 177 4 multip. unsigned long 178 96481280 1024
193 1 text
myisamchk -eis输出的例子：
Checking MyISAM file: company
Key: 1: Keyblocks used: 97% Packed: 0% Max levels: 4
Key: 2: Keyblocks used: 98% Packed: 50% Max levels: 4
Key: 3: Keyblocks used: 97% Packed: 0% Max levels: 4
Key: 4: Keyblocks used: 99% Packed: 60% Max levels: 3
Key: 5: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 6: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 7: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 8: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 9: Keyblocks used: 98% Packed: 0% Max levels: 4
Total: Keyblocks used: 98% Packed: 17%
Records: 1403698 M.recordlength: 226 Packed: 0%
Recordspace used: 100% Empty space: 0% Blocks/Record: 1.00
Record blocks: 1403698 Delete blocks: 0
Recorddata: 317235748 Deleted data: 0
Lost space: 0 Linkdata: 0
User time 1626.51, System time 232.36
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 627, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 639, Involuntary context switches 28966
5 / 21
