能，但需满足SELECT权限且表引擎为MyISAM；InnoDB仅校验页头与索引连通性，不读数据文件，status:OK不代表行数据完好；MyISAM下CHECK TABLE真实读取.MYD和.MYI文件验证物理一致性，Msg_type='Error'表明文件损坏。
CHECK TABLE 能否真正检测 MyISAM 物理损坏？
能，但必须满足两个前提：SELECT 权限 + 表引擎确实是 MyISAM。InnoDB 表执行 CHECK TABLE 仅校验页头校验和与索引树连通性，不读数据文件，所以即使输出 status: OK，也不能说明行数据没损坏。
MyISAM 下，CHECK TABLE 会真实读取 .MYD（数据）和 .MYI（索引）文件，验证指针是否断裂、记录长度是否合法、索引键是否指向有效行等物理层一致性。
- 看到
Msg_type = 'Error'（如Incorrect key file for table或Record-file is crashed），基本可判定.MYI或.MYD文件已损坏 -
Msg_type = 'Warning'（如1 client is using or hasn't closed table）多为并发写入干扰，非物理损坏，需暂停写入后重试 -
Msg_type = 'status'或'info'是运行过程日志，不是问题信号
不同 MODE 对检测深度和性能的影响
CHECK TABLE 的 QUICK、MEDIUM（默认）、EXTENDED 参数，直接决定它“看多深”以及“花多久”：
-
QUICK：只检查索引文件头和唯一键重复性，毫秒级完成，但完全跳过数据块校验——.MYD文件被截断或填充乱码也检测不到 -
MEDIUM（默认）：读取所有索引键，并验证每个键是否能正确定位到对应数据行——能发现大部分指针错位、索引与数据不匹配问题 -
EXTENDED：逐行读取.MYD，校验每条记录结构（如字段长度、NULL 标志位）——唯一能发现单条记录内部损坏的方式，但 I/O 密集，>1GB 表慎用，易触发Waiting for table flush
生产环境建议：日常巡检用 MEDIUM；怀疑数据文件损坏时再跑 EXTENDED，且避开业务高峰。
为什么 CHECK TABLE 报错后不能直接修复？
CHECK TABLE 是只读命令，它加的是 READ LOCAL 锁（MyISAM 允许并发 INSERT，但阻塞 UPDATE/DELETE），不会修改任何文件。它只告诉你“坏了”，不负责“修好”。
- MyISAM 表需后续执行
REPAIR TABLE（或更稳妥的myisamchk --safe-recover本地修复） - InnoDB 表根本不能用
REPAIR TABLE——MySQL 8.0+ 直接报错ERROR 1031 (HY000): Table storage engine for 'xxx' doesn't support repair - 若
.MYD文件彻底丢失或被清空，REPAIR TABLE只能重建空表结构，原始数据无法恢复
CHECK TABLE 在主从环境中的并发风险
别在主库上对大 MyISAM 表跑 EXTENDED 检查，尤其主从复制链路上有延迟时：
- 表锁虽为
READ LOCAL，但EXTENDED模式下大量磁盘 I/O 会拖慢 SQL 线程，拉长Seconds_Behind_Master - 若从库也在同步该表，主库长时间 I/O 等待可能让从库的
SQL Thread卡住，出现Waiting for table metadata lock - 更隐蔽的问题：MyISAM 表未显式关闭（比如 mysqld 异常退出），
CHECK TABLE可能误报Client is using table，实际只需重启 mysqld 清理状态
真正容易被忽略的是：CHECK TABLE 不检查外键约束（MyISAM 本就不支持外键），也不验证用户自定义逻辑一致性——比如金额字段总和是否等于明细汇总，这类必须靠应用层或定期 SQL 校验。
