绝无经由的怎样修复MySQL数据库表
有的时候，一些缺失的功能可以通过别的办法来实现，例如，在MySQL4.1以前，你可以通过使用join方法来替代子查询的功能。在MySQL5.0中，大多数关系型数据库所要求的功能已经都具备。你大概在利用MySQL过程当中，各类不测招致数据库表的破坏，并且这些数据常常是最新的数据，一般不成能在备份数据中找到。本章将继上篇文章中反省出表的成绩后，告知你怎样修复表。一张破坏的表的症状一般是查询不测中止而且你能看到比方这些毛病：
◆“tbl_name.frm”被锁定不克不及改动。
◆不克不及找到文件“tbl_name.MYI”（Errcode：###）。
◆从表处置器的失掉毛病###(此时，毛病135是一个破例)。
◆不测的文件停止。
◆纪录文件被损坏。
在这些情形下，你必需修复表。表的修复是一项十分坚苦的事情，良多情形命令人一筹莫展。但是，有一些惯例的晓得头脑和历程，能够遵守它们来增添修改表的时机。一般，入手下手是能够用最快的修复办法，看看可否袖珍妨碍。假如发明不乐成，能够慢慢晋级到更完全的但更慢的修复办法。假如仍然难以修复，就应当从备份中恢复了。在上一章已具体先容了这一部份内容。
复杂平安的修复
为了修复一个表实行以下步骤：
◆起首，用--recover,-r选项修改表，而且用--quick，-q选项，来只依据索引文件的内容举行恢复。如许不打仗数据文件来修复索引文件。(-r意味着“恢复形式”)
myisamchk-r-qtbl_nameisamchk-r-qtbl_name
◆假如成绩仍然存在，则疏忽--quick选项，同意修复程序修正数据文件，由于这大概存在成绩。上面的命令将从数据文件中删除不准确的纪录和已被删除的纪录偏重建索引文件：
myisamchk-rtbl_nameisamchk-rtbl_name
◆假如后面的步骤失利，利用。平安恢复形式利用一个老的恢复办法，处置惯例恢复形式不可的多数情形(可是更慢)。
myisamchk--safe-recovertbl_nameisamchk--safe-recovertbl_name
坚苦的修缮
假如在索引文件的第一个16K块被损坏，或包括不准确的信息，或假如索引文件丧失，你只应当到这个阶段。在这类情形下，创立一个新的索引文件是需要的。按以下如许的步骤做：
◆定位到包括溃散表的数据库目次中
◆把数据文件移更平安的中央。
◆利用表形貌文件创立新的(空)数据和索引文件：
shell>mysqldb_namemysql>DELETEFROMtbl_name;mysql>quit
上述语句将从头创立新的空表，并利用表的的形貌文件tbl_name.frm从头天生新的数据和索引文件。
◆将老的数据文件拷贝到新创立的数据文件当中。（不要只是将老文件移回新文件当中；你要保存一个正本以防某些器材堕落。）
◆在利用尺度的修复办法。如今myisamchk-r-q应当事情了。（这不该该是一个无穷轮回）。
假如你具有表的备份文件，那末统统历程就简单的多。从备份文件中能够恢复表的形貌文件，然后在反省表，有大概还要持续利用尺度的修复办法，应当纠能够办理成绩了。
十分坚苦的修复
只要形貌文件也损坏了，你才应当抵达这个阶段。这应当从未产生过，由于在表被创立今后，形貌文件就不再改动了。
从一个备份恢复形貌文件而且回到阶段2。你也能够恢复索引文件而且回到阶段1。关于后者，你应当用myisamchk-r启动。
假如由于某种缘故原由，数据的备份文件丧失大概没有备份文件，可是你还记得创建表的CREATETABLE语句，那末太好了，如许仍是能够恢复索引文件：
◆定位到包括溃散表的数据库目次中
◆把数据文件移更平安的中央。再把数据库目次中的对应的目次删往.。
◆挪用mysql并发复CREATETABLE语句创建该表。
◆加入mysql，将原始的数据文件和索引文件移回到数据库的目次中，交换方才新建的文件。
◆然后回到阶段2，修复表。也能够只移回数据文件，如许保存新的形貌和索引文件，然后回到阶段1，持续用尺度的办法修复表。
一个相关的问题是第三方支持的资格问题，尽管直接来自厂商的支持和服务可以一定程度上减缓这个问题，但是，对于有的企业来说，通过强有力的本地化支持显然更有吸引力。 理解了存储结构，再阅读下性能优化的章节基本上会对sqlserver有个清晰地认识 连做梦都在想页面结构是怎么样的，绝非虚言 始终遗憾SQLServer的登陆无法分配CPU/内存占用等指标数。如果你的SQLServer给别人分配了一个只可以读几个表的权限，而这个家伙疯狂的死循环进行连接查询，会给你的系统带来很大的负担。 这就引发了对varchar和char效率讨论的老问题。到底如何分配varchar的数据，是否会出现大规模的碎片？ 始终遗憾SQLServer的登陆无法分配CPU/内存占用等指标数。如果你的SQLServer给别人分配了一个只可以读几个表的权限，而这个家伙疯狂的死循环进行连接查询，会给你的系统带来很大的负担。 原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。 换言之，只有在不断的失败中尝试成功，而关于失败的总结却是很少的
页:
[1]