# 更新包含分区的表
<a name="updates-and-partitions"></a>

在 Athena 中，一个表及其分区必须使用相同的数据格式，但它们的架构可以不同。当您创建一个新分区时，该分区通常继承表的架构。随着时间的推移，该架构可能开始变得不同。原因包括：
+ 当您的表的架构发生变化时，分区架构没有更新，从而没有保持与表的架构同步。
+ AWS Glue 爬网程序允许您发现具有不同架构的分区中的数据。这意味着，假如您使用 AWS Glue 在 Athena 中创建了一个表，则当爬网程序完成处理后，该表的架构及其分区可能会有所不同。
+ 如果您直接使用 AWS API 添加分区。

如果分区满足以下约束，Athena 会成功地处理具有分区的表。如果不满足这些约束，Athena 会发出 HIVE\$1PARTITION\$1SCHEMA\$1MISMATCH 错误。
+ 每个分区的架构与表的架构兼容。
+ 表的数据格式允许您要执行的更新类型：添加、删除、重新排序列或更改列的数据类型。

  例如，对于 CSV 和 TSV 格式，您可以将列重命名，在表的最后添加新列，并将列的数据类型更改为其他兼容类型，但您无法删除列。对于其他格式，可以添加或删除列，或者将列的数据类型更改为其他兼容类型。有关信息，请参阅[摘要：Athena 中的更新和数据格式](handling-schema-updates-chapter.md#summary-of-updates)。

## 避免带有分区的表出现架构不匹配错误
<a name="partitions-dealing-with-schema-mismatch-errors"></a>

在查询执行开始时，Athena 通过检查表和分区之间每个列数据类型是否兼容来验证表的架构。
+ 对于 Parquet 和 ORC 数据存储类型，Athena 依赖于列名，并将其用于基于列名的架构验证。这消除了具有 Parquet 和 ORC 格式分区的表的 `HIVE_PARTITION_SCHEMA_MISMATCH` 错误。(如果 SerDe 属性设置为按名称访问索引，则对于 ORC 来说此为真：`orc.column.index.access=FALSE`。Parquet 默认按名称读取索引)。
+ 对于 CSV、JSON 和 Avro，Athena 使用基于索引的架构验证。这意味着，如果您遇到架构不匹配错误，则应删除导致架构不匹配的分区并创新创建它，以便 Athena 可以成功地查询它。

 Athena 会将表的架构与分区架构做比较。假如您使用 AWS Glue 爬网程序在 Athena 中创建了一个 CSV、JSON 和 AVRO 格式的表，则在爬网程序完成处理后，该表的架构和其分区的架构可能会不同。如果表的架构与分区架构之间存在不匹配，则您的 Athena 查询将因类似如下的架构验证错误而失败：'crawler\$1test.click\$1avro' is declared as type 'string', but partition 'partition\$10=2017-01-17' declared column 'col68' as type 'double'. ('crawler\$1test.click\$1avro' 声明为类型 'string'，但分区 'partition\$10=2017-01-17' 声明列 'col68' 的类型为 'double'。)

对于此类错误，通常的解决方法是删除导致错误的分区并重新创建它。有关更多信息，请参阅 [ALTER TABLE DROP PARTITION](alter-table-drop-partition.md) 和 [ALTER TABLE ADD PARTITION](alter-table-add-partition.md)。