<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>寂静的深海 &#187; OPTIMIZE</title>
	<atom:link href="http://www.deepseath.com/?feed=rss2&#038;tag=optimize" rel="self" type="application/rss+xml" />
	<link>http://www.deepseath.com</link>
	<description></description>
	<lastBuildDate>Mon, 29 Jan 2024 09:55:11 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>error 1030 got error 127 from table handler</title>
		<link>http://www.deepseath.com/?p=402</link>
		<comments>http://www.deepseath.com/?p=402#comments</comments>
		<pubDate>Tue, 11 Nov 2008 08:06:37 +0000</pubDate>
		<dc:creator>Deepseath</dc:creator>
				<category><![CDATA[日积月累]]></category>
		<category><![CDATA[MYI]]></category>
		<category><![CDATA[myisamchk]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[OPTIMIZE]]></category>
		<category><![CDATA[shell]]></category>

		<guid isPermaLink="false">http://www.deepseath.com/?p=402</guid>
		<description><![CDATA[转自网络，修复损坏的数据表。我的经验是，修复大数据的时候最好将mysql关闭或者避免有其他应用程序正在访问数据表。否则有可能造成不必要的麻烦，我经历过那种恶梦……:( 问题： &#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;     在使用mysql的过程中,机器重启后     使用一个表,提示 error 1030 got error 127 from table handler &#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;- 解决方案： &#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;- 其实就是将损坏的表进行修复。 1,简单的修复模式myisamchk -r -q path/数据库/坏表.MYI 注:-r     &#8212;-恢复模式     -q     &#8212;-快速修复 2,使用安全修复模式 myisamchk &#8211;safe-recover path/数据库/坏表.MYI 3,困难的修复模式 如果在索引文件的第一个16K块被破坏，或包含不正确的信息，或如果索引文件丢失，你只应该到这个阶段 。在这种情况下，创建一个新的索引文件是必要的。按如下这样做： 把数据文件移更安全的地方。 使用表描述文件创建新的(空)数据和索引文件： shell&#62; mysql db_name mysql&#62; DELETE FROM tbl_name; mysql&#62; quit 将老的数据文件拷贝到新创建的数据文件之中。（不要只是将老文件移回新文件之中；你要保留一个副本以防某些东西出错。） 回到阶段2。现在myisamchk -r -q应该工作了。（这不应该是一个无限循环)。 4,非常困难的修复模式 只有描述文件也破坏了，你才应该到达这个阶段。这应该从未发生过，因为在表被创建以后，描述文件就不再改变了。 从一个备份恢复描述文件并且回到阶段3。你也可以恢复索引文件并且回到阶段2。对后者，你应该用myisamchk -r启动。 如果你没有一个备份但是确切地知道表是怎样被创建的，在另一个数据库中创建表的一个拷贝。删除新的数据文件，然后从其他数据库将描述和索引文件移到破坏的数据库中。这给了你新的描述和索引文件，但是让数据文件独自留下来了。回到阶段2并且尝试重建索引文件。 5,优化表结构 [...]]]></description>
		<wfw:commentRss>http://www.deepseath.com/?feed=rss2&#038;p=402</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
