创建/导入TSV文件后Athena查询返回零结果，已执行MSCK REPAIR TABLE求排查

我来帮你梳理下可能导致这个问题的高频场景，都是日常排查这类故障时碰到的典型情况：

• 文件路径与表LOCATION不匹配
  先确认表的存储路径是否正确。执行SHOW CREATE TABLE your_table_name查看LOCATION参数，然后去S3控制台核对这个路径下是否真的存在你的TSV文件。常见错误包括桶名拼写错误、路径层级写错（比如把/data/tsv/写成了/data/csv/），或者文件放在了LOCATION指定路径的子目录之外。

• TSV格式不符合LazySimpleSerDe的解析规则
  官方示例默认用**制表符（\t）**作为字段分隔符，如果你的文件实际用了其他分隔符（比如空格、竖线、逗号），SerDe会无法正确解析字段，导致所有行被判定为无效数据。可以：

  1. 下载一小段样本文件，用文本编辑器打开查看实际分隔符；
  2. 执行SELECT * FROM your_table_name LIMIT 1，如果返回解析错误，就说明格式不匹配；
  3. 还要检查字段数量是否和表定义一致——比如表定义了6个字段，但文件里某行有7个分隔符，这行就会被过滤，如果所有行都存在这个问题，查询就会返回0。

• 压缩文件未指定压缩格式
  如果你的TSV文件是压缩格式（比如.gz、.bz2），但表定义里没有声明压缩类型，Athena无法正确解压读取。需要在表定义中添加压缩配置，比如：

  CREATE TABLE your_table_name (
    col1 string,
    col2 int
  )
  ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t'
  STORED AS TEXTFILE
  WITH SERDEPROPERTIES (
    "serialization.format" = "\t",
    "compression.type" = "gzip"
  )
  LOCATION 's3://your-bucket/path/';
  

• 分区表的分区路径不符合规范
  如果你的表是分区表，要确保S3上的分区路径遵循partition_key=value的格式（比如year=2024/month=06）。如果路径命名不符合这个规则，MSCK REPAIR TABLE无法识别分区，查询时如果没有指定具体分区，就会返回0条记录。这种情况可以重新调整S3路径命名，或者手动添加分区：

  ALTER TABLE your_table_name ADD PARTITION (year='2024', month='06') LOCATION 's3://your-bucket/path/2024/06/';
  

  另外，非分区表不需要执行MSCK REPAIR TABLE，这个命令只对分区表生效。

• IAM角色权限不足
  检查Athena执行查询使用的IAM角色是否拥有访问目标S3路径的权限，至少需要s3:GetObject（读取文件）和s3:ListBucket（列出目录）权限。如果角色缺少权限，Athena无法读取文件，自然返回0条记录。可以去IAM控制台查看角色的权限策略，或者用AWS CLI测试是否能访问该S3路径。

• 文件为空或数据格式与表类型不匹配
  先确认S3上的文件不是空文件（大小为0），如果所有文件都为空，查询肯定返回0。另外，如果表定义的数据类型和文件中实际值不匹配（比如表定义col1 int，但文件里该列是字符串或空值），SerDe解析时会过滤掉这些行。可以临时把所有字段改成STRING类型重新建表测试，如果能查到数据，再逐个调整字段类型。

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