|
对--set-variable(-O)选项,可能的变量是: key_buffer_size当前值:16776192read_buffer_size当前值:262136write_buffer_size当前值:262136sort_buffer_size当前值:2097144sort_key_blocks当前值:16decode_bits当前值:9 13.1.2myisamchk内存使用当你运行myisamchk时,内存分配很重要。myisamchk使用不超过你用-O选项指定的内存量。如果你想在很大的文件上使用myisamchk,你首先应该确定你想要它使用多少内存。缺省仅使用大约3M来修复。通过使用更大的值,你能使myisamchk更快地操作。例如,如果你有多于32M内存,你能使用例如这些选项(除了任何你可能指定的选项): shell>myisamchk-Osort=16M-Okey=16M-Oread=1M-Owrite=1M... 使用-Osort=16M应该可能对大多数情形就足够了。 必须明白,myisamchk使用在TMPDIR里面的临时文件。如果TMPDIR指向一个内存文件系统,你可能很容易得到内存溢出的错误。如果它发生,设定TMPDIR指向有更多空间的某个目录并且重启myisamchk。 13.2建立一个数据库表维护规范在一个定期基础而非等到问题出现才实施数据库表的检查是一个好主意。为维护目的,你能使用myisamchk-s检查桌子。-s选项使myisamchk以沉默模式运行,当错误出现时,仅仅打印消息。 在服务器启动时检查表是一个好主意。例如,无论何时机器在更新当中重新启动了,你通常需要检查所有可能被影响了的表。(这是一个“期望破坏了的表”)如果重启后有一个旧的“.pid”(进程ID),你能为safe_sql/Index.html'>mysqld加入一个测试,运行myisamchk检查所有在过去24小时修改过的表)。(“.pid”文件在sql/Index.html'>mysqld启动时由它创建,并它正常终止时删除。在系统启动时存在一个“.pid”文件表明sql/Index.html'>mysqld异常地终止了。) 一个更好的测试将是检查任何表,它的最后修改时间是比“.pid”文件更新。 你也应该定期在正常系统操作期间检查表。在TcX,我们运行一个cron任务,每周一次检查我们所有重要的表,在一个“crontab”文件中使用这样的行: 350**0/path/to/myisamchk-s/path/to/datadir/*/*.MYI 这打印出损坏的表的信息,因此我们能检验并且在需要时修复他们。 当我们现在几年(这确实是真的)都没有任何意外损坏的表时(由于除硬件故障外的其他原因造成损坏的表),每周一次对我们是足够了。 我们建议现在开始,你对所有最后24小时内被更新了表每晚都执行myisamchk-s,直到你变得象我们那样信任MySQL。 13.3获得关于一个表的信息为了获得关于一个表的描述或统计,使用显示在下面的命令。我们以后更详细地解释某些信息。myisamchk-dtbl_name以“描述模式”运行myisamchk,生成你的表的描述。如果你用--skip-locking选项启动MySQL服务器,myisamchk可以当它运行时报告被一个更新的表的错误。然而,既然在描述模式中myisamchk不改变表,没有破坏数据的任何风险。myisamchk-d-vtbl_name为了生成更多关于myisamchk正在做什么的信息,加上-v告诉它以冗长模式运行。myisamchk-eistbl_name仅显示一个表最重要的信息。因为必须读取整个表,它很慢。myisamchk-eivtbl_name这类似-eis,只是告诉你正在做什么。myisamchk-d输出的例子:
MyISAMfile:company.MYIRecordformat:FixedlengthDatarecords:1403698Deletedblocks:0Recordlength:226tabledescription:KeyStartLenIndexType128uniquedouble21510multip.textpackedstripped32198multip.double46310multip.textpackedstripped51672multip.unsignedshort61774multip.unsignedlong71554multip.text81384multip.unsignedlong91774multip.unsignedlong1931text 上一页 [1] [2] [3] [4] [5] [6] 下一页
|