Amazon Athena执行ALTER TABLE ADD PARTITION后统计记录数异常

我之前在Athena操作分区的时候也踩过类似的坑，结合你的情况，咱们从几个关键点入手排查：

1. 首先检查ADD PARTITION语句的语法错误 #

你给出的命令里，location参数的单引号没有闭合：

ALTER TABLE table_name ADD PARTITION (dt='2018-03-01') location 's3://my_data/my_folder/

这会导致分区根本无法成功添加，自然统计不到对应的数据。修正后的语句应该是（注意补上末尾的单引号，同时建议路径对应分区键的规范格式）：

ALTER TABLE table_name ADD PARTITION (dt='2018-03-01') location 's3://my_data/my_folder/dt=2018-03-01/';

如果你的数据确实存放在s3://my_data/my_folder/而不是子目录，那确保单引号闭合即可，但规范的分区路径（带dt=xxx）更利于后续的分区管理和元数据同步。

2. 确认分区是否真的被添加成功 #

执行完ALTER语句后，跑这条命令验证分区是否存在：

SHOW PARTITIONS table_name;

如果列表里没有dt=2018-03-01，说明分区添加失败，回头检查语法、S3路径权限（Athena角色是否有该S3目录的读权限）、路径是否存在。

3. 检查分区目录下的数据是否符合表定义 #

• 确认S3目录s3://my_data/my_folder/（或对应的分区子目录）下有合法的数据文件（比如Parquet、ORC、CSV等，和你表的存储格式一致）。
• 如果表是带SerDe定义的（比如CSV的分隔符、Parquet的压缩格式），确保文件格式和表定义匹配，否则Athena无法解析这些数据，统计结果会缺失。
• 可以先针对性查询该分区的数据，验证是否能读取：

SELECT * FROM table_name WHERE dt='2018-03-01' LIMIT 10;

如果这条查询返回空，说明数据本身无法被Athena识别，需要检查文件格式或表结构。

4. 刷新元数据缓存 #

有时候Athena的元数据缓存会导致新分区无法立即被识别，你可以尝试运行MSCK命令同步元数据：

MSCK REPAIR TABLE table_name;

这条命令会自动发现并添加S3路径下符合规范的分区，同时刷新元数据，之后再重新执行count查询。

最后再验证统计结果 #

当以上步骤都确认没问题后，重新运行：

SELECT count(1) from table_name;

应该就能得到正确的记录数了。

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