MySQL CHECK TABLE 分区表怎样排查分区损坏

分区表出现读取异常、索引报错或“corrupt”标记时，先不要直接执行修复语句。正确的排查顺序是：确认存储引擎和分区范围，运行 CHECK TABLE 或针对分区的 ALTER TABLE ... CHECK PARTITION，再按返回结果决定备份、重建或升级处理。CHECK TABLE 的结果集最后一行通常是 Msg_type=status，但它不等于“所有数据、表空间头部和业务逻辑都绝对安全”。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/check-table.html

本文按 MySQL 8.4 官方手册说明命令边界，示例中的库名、表名和分区名均为占位符，不代表已经在某个线上实例执行。

先确认引擎、分区和权限

第一步不是立刻全表扫描，而是把对象范围固定下来。执行账号至少要对目标表拥有某种权限；同时要确认表确实是分区表，以及分区使用的是 InnoDB 还是 MyISAM，因为不同引擎对检查选项的处理不同。

-- 只读查询：先记录引擎、分区方法和每个分区的边界。
SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE, CREATE_OPTIONS
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'app_db'
  AND TABLE_NAME = 'orders';

-- 只读查询：确认分区名称、行数估计与分区表达式信息。
SELECT PARTITION_NAME, PARTITION_METHOD, PARTITION_EXPRESSION,
       TABLE_ROWS, PARTITION_DESCRIPTION
FROM information_schema.PARTITIONS
WHERE TABLE_SCHEMA = 'app_db'
  AND TABLE_NAME = 'orders'
  AND PARTITION_NAME IS NOT NULL
ORDER BY PARTITION_ORDINAL_POSITION;

如果 ENGINE 是 InnoDB，优先把重点放在错误信息、索引状态和备份恢复路径；如果是 MyISAM，FAST、CHANGED、MEDIUM 等选项才有更直接的意义。分区名来自数据字典，不能凭日期或业务习惯猜测。

先做整表或单分区检查

已知只有某个分区异常时，可以把检查范围缩小；症状不明确时先检查整表，避免只检查一个分区而漏掉其它分区的错误。

-- 常规整表检查：读取每个对象的状态行和消息行。
CHECK TABLE app_db.orders;

-- 只检查指定分区：分区名必须来自数据字典，不能写成日期猜测。
ALTER TABLE app_db.orders CHECK PARTITION p202611;

-- 一次检查多个已确认存在的分区，便于缩小故障范围。
ALTER TABLE app_db.orders CHECK PARTITION p202610, p202611;

重点看返回的 Table、Op、Msg_type 和 Msg_text。最后的 status/OK 或“already up to date”表示该次检查没有报告问题；若出现 error 或 warning，要保留完整输出、时间、实例和分区名，再进入恢复流程。不要只复制最后一行，前面的 info 或 note 可能包含定位线索。

对 InnoDB，大表检查可能让其它线程等待；生产环境应先安排低峰窗口，并准备可回退的备份。若只想缩小一次检查的扫描范围，QUICK 可以跳过部分行链接检查，但它不是“更可靠”的模式。

按存储引擎解释 CHECK TABLE 选项

常见误区是把所有选项都当成通用的“更彻底检查”。官方手册明确说明，部分选项会被 InnoDB 忽略：

尤其不要把 CHECK TABLE ... EXTENDED 当作无风险升级：它可能影响优化器生成的执行计划，而且在 InnoDB 上并不会把所有底层问题都变成可见结果。若是 InnoDB 页面损坏，官方手册还提示检查可能导致服务退出；这类情况应优先依照备份、只读副本和恢复预案处理。

遇到损坏结果怎样收口

检查报错后，先保存原始结果并停止无计划的写入和重复检查。对于 InnoDB，不要照搬 MyISAM 的 REPAIR TABLE 思路；应结合错误类型、备份可用性、只读副本和官方恢复建议制定方案。对于索引条目数量不一致等情况，也要先确认业务是否允许重建索引或表，再安排变更。

如果整表检查为 OK，但查询仍然报错，下一步可以把问题拆成索引、表空间文件、分区定义和应用查询四个方向；CHECK TABLE 不会替代 innochecksum 对 InnoDB 独立表空间全部页面头部的检查，也不会证明业务数据语义正确。最终记录应包含实例、版本、表名、分区名、引擎、完整输出和后续动作。

常见问题

CHECK TABLE 返回 OK 就能继续高风险变更吗？

不能。它只说明本次检查没有报告对应错误，仍要结合备份、实例错误日志、表空间状态和业务读写表现。

为什么 CHECK TABLE 分区表没有告诉我是哪一行数据坏了？

该语句主要检查表和索引结构，返回的是检查消息，不是逐行业务数据审计。需要结合引擎能力和备份恢复工具继续定位。

能不能直接用 REPAIR TABLE 修复 InnoDB 分区？

不要这样泛化。先确认引擎和官方支持范围；InnoDB 出现损坏时应走备份恢复、重建或专项故障处理流程。

参考入口：https://dev.mysql.com/doc/refman/8.4/en/check-table.html；分区维护：https://dev.mysql.com/doc/refman/8.4/en/partitioning-maintenance.html。