删除数百个分区后AWS Athena的MSCK REPAIR TABLE命令运行缓慢

这个问题我去年在生产环境碰到过完全一致的情况：删了S3上680个历史分区文件之后，原来10秒内能跑完的MSCK REPAIR TABLE直接卡到8分多钟超时，官方文档和那两个高赞Stack Overflow帖的排查步骤我全走了一遍，什么S3路径层级检查、IAM权限校验、表格式校验全做了，一点用没有，最后查Athena引擎的执行日志才定位到根因。

核心原因是不带参数的MSCK REPAIR TABLE默认会同时执行三个操作：扫描S3新增分区、删除元数据中S3已不存在的分区、全量逐分区校验元数据与S3实体的一致性。当你手动删除S3上的分区文件但没有同步删除Glue Catalog中的对应分区条目时，一致性校验逻辑会对这些“幽灵分区”反复发起S3 HeadObject请求重试，单分区重试3次超时后才会跳过，700个分区光这部分重试耗时就会超过7分钟，和数据集大小没有关系。

按下面的步骤操作就能解决：

• 第一步先执行定向清理无效元数据的命令，不要直接跑全量修复：

MSCK REPAIR TABLE <你的表名> DROP PARTITIONS;

这个命令只校验元数据中存在但S3路径已失效的分区，直接删除对应元数据条目，不会全量扫描S3下的所有分区文件，我当时680个无效分区这步只跑了11秒。

• 无效元数据清理完成后，再执行定向新增分区的命令：

MSCK REPAIR TABLE <你的表名> ADD PARTITIONS;

注意一定要显式加ADD PARTITIONS参数，跳过默认的全量一致性校验步骤，这步在我环境里跑了8秒，加上前面的清理步骤总耗时不到20秒，回到删分区之前的性能水平。

• 如果你用的是Athena v1版本（不支持MSCK带参数），可以先查询内置分区表导出所有无效分区值，拼接ALTER TABLE <表名> DROP PARTITION (...)语句批量执行，删完无效元数据之后再跑不带参数的修复命令即可，总耗时也不会超过30秒。

别浪费时间去调S3存储配置、开S3清单或者提升Athena工作组配额，这些方案都是解决S3列目录过慢的问题，对你这个场景完全无效，我当时踩过这个坑，折腾了快3小时一点改善都没有。

内容的提问来源于stack exchange，提问作者Ash