check table对innodb和myisam结果含义不同：myisam校验数据与索引文件物理一致性，ok表示结构完整；innodb仅验证页校验和与事务日志可回放性，ok不保证二级索引同步或大字段未截断。
为什么CHECK TABLE对InnoDB和MyISAM返回结果含义不同
CHECK TABLE 命令在两种引擎下都可执行，但背后验证逻辑完全不同。MyISAM会逐行校验数据文件（.MYD）与索引文件（.MYI）的一致性，包括行长度、键值指向、空闲链表等，失败时通常能准确定位损坏位置；InnoDB则主要依赖页校验和（page checksum）+ 事务系统一致性检查，它不校验二级索引内容是否与主键索引匹配，也不验证溢出列（如TEXT、BLOB）的实际内容是否被截断。
常见错误现象：CHECK TABLE 返回 OK，但业务查询发现某条记录的 description 字段为空或乱码；或者外键关联的记录在从库上缺失，而主库 CHECK TABLE 却无报错。
- MyISAM：若返回
status: OK，基本可认为物理结构完整（不含逻辑误删） - InnoDB：返回
OK仅说明页未损坏、事务日志可回放，不保证二级索引同步、不保证大字段未被静默截断 - 两者都不检测字符集降级（如
utf8mb4 → utf8）、时区偏移导致的DATETIME值漂移、ENUM值变更后的非法存储
用CHECKSUM TABLE对比时，InnoDB默认模式几乎没用
CHECKSUM TABLE 在 MyISAM 下计算的是整张表所有行的 CRC32 校验和，结果稳定可复现；但在 InnoDB 中，默认行为只校验主键索引页（PRIMARY B-tree 的叶子节点），跳过所有二级索引页、溢出页（LOB pages）、甚至部分非叶节点——这意味着即使二级索引已损坏或与主键数据脱节，CHECKSUM TABLE t 仍可能返回相同数值。
实操建议：
- MyISAM 表恢复后，直接比对备份时存档的
CHECKSUM TABLE值即可快速判断是否物理一致 - InnoDB 表必须加
EXTENDED参数：CHECKSUM TABLE t EXTENDED，否则校验覆盖严重不足 -
EXTENDED模式会触发全表扫描 + 所有索引页校验，期间锁表（read lock），生产环境需避开高峰 - 遇到返回
NULL，不是“没数据”，而是底层页损坏严重，立刻查SHOW ENGINE INNODB STATUS中Corruption段落
COUNT(*) 相同 ≠ 数据一致，尤其对MyISAM是假阳性高发区
MyISAM 在表结构文件（.frm）里缓存了精确行数，所以 SELECT COUNT(*) FROM t 是 O(1) 级别响应；InnoDB 则需实际遍历（除非启用了统计持久化且未过期）。但正因如此，MyISAM 的 COUNT(*) 完全无法反映数据逻辑问题：
- MyISAM 表被误删部分行后手动修复（
REPAIR TABLE），行数可能自动补回脏数据，COUNT(*)不变但内容已错 - MyISAM 允许插入超出
ENUM定义的值（转为''或默认值），COUNT(*)不体现这类静默变更 - InnoDB 虽需扫描，但至少能暴露部分逻辑异常（如
WHERE条件查不到本该存在的记录），不过仍无法发现字段值被截断或编码错乱 - 更可靠的做法：对关键字段做
MD5(GROUP_CONCAT(order_id ORDER BY order_id))抽样校验，但要注意GROUP_CONCAT有长度限制（group_concat_max_len）
真正要盯住的不是引擎差异，而是静默失败场景
无论是 InnoDB 还是 MyISAM，最危险的数据完整性破坏都发生在“没报错、没警告、查询还能返回结果”的情况下。比如：
- 从 MySQL 5.7 升级到 8.0 后，
TIMESTAMP默认时区行为变化，历史记录时间集体偏移 8 小时 - 备份恢复时用
mysqldump --default-character-set=latin1导出 utf8mb4 表，再导入到新实例，中文变成问号但CHECK TABLE依然通过 - MyISAM 表用
ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4时未指定COLLATE，导致排序规则降级，WHERE name = '张'查不到数据 - InnoDB 表启用
innodb_strict_mode=OFF时插入超长字符串，被静默截断，且不报 Warning
这些都不会触发 CHECK TABLE 或 CHECKSUM TABLE 报错，必须结合业务规则写断言 SQL（例如：“所有订单状态必须属于 ('pending','paid','shipped') 集合”），否则很容易漏掉。
