可以使用语句检查表。如果结果的msg_text部分是好的，那么你的表是健康的。反之，则表明mysql数据库中的表有损坏。另外有些厉害的高手一额可以通过运行脚本来检测。
成都创新互联是一家集网站建设,仁布企业网站建设,仁布品牌网站建设,网站定制,仁布网站建设报价,网络营销,网络优化,仁布网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。
MyISAM 表可以采用以下方法进行修复 ：使用 reapair table 或myisamchk 来修复。如果修复无效，采用备份恢复表。
阶段1 ：检查你的表
如果你有很多时间，运行myisamchk *.MYI 或myisamchk -e *.MYI 。使用-s （沉默）选项禁止不必要的信息。如果mysqld 服务器处于宕机状态，应使用--update-state 选项来告诉myisamchk 将表标记为' 检查过的' 。
你必须只修复那些myisamchk 报告有错误的表。对这样的表，继续到阶段2 。如果在检查时，你得到奇怪的错误( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。
阶段2 ：简单安全的修复
注释：如果想更快地进行修复，当运行myisamchk 时，你应将sort_buffer_size 和Key_buffer_size 变量的值设置为可用内存的大约25% 。
首先，试试myisamchk -r -q tbl_name(-r -q 意味着“ 快速恢复模式”) 。这将试图不接触数据文件来修复索引文件。如果数据文件包含它应有的一切内容和指向数据文件内正确地点的删除连接，这应该管用并且表可被修复。开始修复下一张表。否则，执行下列过程：
在继续前对数据文件进行备份。使用myisamchk -r tbl_name(-r 意味着“ 恢复模式”) 。这将从数据文件中删除不正确的记录和已被删除的记录并重建索引文件。
如果前面的步骤失败，使用myisamchk --safe-recover tbl_name 。安全恢复模式使用一个老的恢复方法，处理常规恢复模式不行的少数情况( 但是更慢) 。如果在修复时，你得到奇怪的错误( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。
阶段3 ：困难的修复
只有在索引文件的第一个16K 块被破坏，或包含不正确的信息，或如果索引文件丢失，你才应该到这个阶段。在这种情况下，需要创建一个新的索引文件。按如下步骤操做：
把数据文件移到安全的地方。使用表描述文件创建新的( 空) 数据文件和索引文件：
shell mysql db_name
mysql SET AUTOCOMMIT=1;
mysql TRUNCATE TABLE tbl_name;
mysql quit
如果你的MySQL 版本没有TRUNCATE TABLE ，则使用DELETE FROM tbl_name 。将老的数据文件拷贝到新创建的数据文件之中。回到阶段2 。现在myisamchk -r -q 应该工作了。你还可以使用REPAIR TABLE tbl_name USE_FRM ，将自动执行整个程序。
阶段4 ：非常困难的修复
只有.frm 描述文件也破坏了，你才应该到达这个阶段。这应该从未发生过，因为在表被创建以后，描述文件就不再改变了。
从一个备份恢复描述文件然后回到阶段3 。你也可以恢复索引文件然后回到阶段2 。对后者，你应该用myisamchk -r 启动。
如果你没有进行备份但是确切地知道表是怎样创建的，在另一个数据库中创建表的一个拷贝。删除新的数据文件，然后从其他数据库将描述文件和索引文件移到破坏的数据库中。这样提供了新的描述和索引文件，但是让.MYD 数据文件独自留下来了。回到阶段2并且尝试重建索引文件。
mysql判断符合查询条件的数据有两条根据查询相关资料：
1、查询数据库表数据，根据指定条件筛选出满足条件的数据，此例返回满足条件的两条数据。
2、关键字查询，使用AND搜索栏输入符合条件的数据。
1、创建测试表，
create table test_limit(id int ,value varchar(100));
2、插入测试数据，共6条记录；
insert into test_limit values (1,'v1');
insert into test_limit values (2,'v2');
insert into test_limit values (3,'v3');
insert into test_limit values (4,'v4');
insert into test_limit values (5,'v5');
insert into test_limit values (6,'v6');
3、查询表中全量数据，可以发现共6条数据，select * from test_limit t;
4、编写语句，指定查询3条数据；
select * from test_limit limit 3;
用 pt-table-checksum 时，会不会影响业务性能？
实验
实验开始前，给大家分享一个小经验：任何性能评估，不要相信别人的评测结果，要在自己的环境上测试，并（大概）知晓原理。
我们先建一对主从：
然后用 mysqlslap跑一个持续的压力：
开另外一个会话，将 master 上的 general log 打开：
然后通过 pt-table-checksum 进行一次比较：
查看 master 的 general log，由于 mysqlslap 的影响，general log 中有很多内容，我们找到与 pt-table-checksum 相关的线程：
将该线程的操作单独列出来：
操作比较多，我们一点一点来说明：
这里工具调小了 innodb 锁等待时间。使得之后的操作，只要在 innodb 上稍微有锁等待，就会马上放弃操作，对业务影响很小。
另外工具调小了 wait_timeout 时间，倒是没有特别的作用。
工具将隔离级别调整为了 RR 级别，事务的维护代价会比 RC 要高，不过后面我们会看到工具使用的每个事务都很小，加上之前提到 innodb 锁等待时间调到很小，对线上业务产生的成本比较小。
RR 级别是数据对比的基本要求。
工具通过一系列操作，了解表的概况。工具是一个数据块一个数据块进行校验，这里获取了第一个数据块的下边界。
接下来工具获取了下一个数据块的下边界，每个 SQL前都会 EXPLAIN 一下，看一下执行成本，非常小心翼翼。
之后工具获取了一个数据块的 checksum，这个数据块不大，如果跟业务流量有冲突，会马上出发 innodb 的锁超时，立刻退让。
以上是 pt-table-checksum 的一些设计，可以看到这几处都是精心维护了业务流量不受影响。
工具还设计了其他的一些机制保障业务流量，比如参数 --max-load 和 --pause-file 等，还有精心设计的数据块划分方法，索引选择方法等。大家根据自己的情况配合使用即可达到很好的效果。
总结
本期我们介绍了简单分析 pt-table-checksum 是否会影响业务流量，坊间会流传工具的各种参数建议或者不建议使用，算命的情况比较多，大家都可以用简单的实验来分析其中机制。
还是那个观点，性能测试不能相信道听途说，得通过实验去分析。
