问题背景:
和往常一样正常上班,打开数据表不带任何条件执行一条SQL查询语句,结果数据记录显示完好, 后来根据ID直接查询某条数据记录,却死活查不出来,但是like模糊查询数据也完好的出来了,甚是诡异。
问题原因:
1. 根据网上资料查证,认为是表ID数据不干净,也就是说可能被认为的修改过,带入了不可见的字符比如:空格、制表符等等, 存在这种可能性
2. 根据经验多半是数据表损坏了【当时我们遇到的是这种情况,因为突然想起周五下班突然断电了,恩,八成是这原因】
解决方法:
myisamchk知识补充
在检查、修复表,除了用myisamchk,还可以用check table、repair table来完成,下面来总结下:
1.检查表是否有错误
CHECK TABLE对MyISAM和InnoDB表有作用。对于MyISAM表,关键字统计信息会被更新,CHECK TABLE也可以检查视图是否有错误,比如在视图定义中被引用的表已不存在。
一些只对myisam表有作用(对innodb和视图无效)的选项介绍:
QUICK:不扫描行,不检查错误的链接。
FAST:只检查没有被正确关闭的表。
CHANGED:只检查自上次检查后被更改的表,和没有被正确关闭的表。
MEDIUM:扫描行,以验证被删除的链接是有效的。也可以计算各行的关键字校验和,并使用计算出的校验和验证这一点。
EXTENDED:对每行的所有关键字进行一个全面的关键字查找。这可以确保表是100%一致的,但是花的时间较长,所以很少使用。
常用的全面常规检查
mysql> check table table medium; (等价于myisamchk --medium-check table)
快速检查没有被正确关闭的表
mysql> check table table quick fast;
2. 修复有错误的表
REPAIR TABLE用于修复被破坏的表。
默认情况下,REPAIR TABLE与myisamchk --recover tbl_name等价。
REPAIR TABLE 对 MyISAM 和 ARCHIVE表起作用
语法如下:
REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ... [QUICK] [EXTENDED] [USE_FRM]
quick:repair只修复索引,等价于“myisamchk --recover --quick tablename”
extended:MySQL会一行一行地创建索引行,等价于”myisamchk --safe-recover tablename“
use_frm:如果.MYI索引文件缺失或标题被破坏,则使用此选项,用来自.frm文件重新创建.MYI文件。这种修复不能使用myisamchk来完成;在repair常规无法完成时,才会使用这个选项,如果表被压缩不能使用。
no_write_to_binlog:repair默认是写到二进制文件的,如果有主从模式的话,repair也会在从库执行;使用此选项将会禁止写入到二进制文件中。