ByteHouse 建表时，配置的参数字段大部分无法在创建完成后修改，请在建表前仔细阅读该指南进行合理规划。

1. 排序键 （必填）Order By #

• 定义与原理：为了提高查询性能，存储数据时会根据排序索引顺序存储。（ 排序索引并不等同于 MySQL 的主键，值可以重复；也不等同于 MySQL 的索引，在建表后无法修改 ）
• 字段限制：不能为 Nullable，支持设置 1-5 个字段。
• 配置建议：选择 1-3 个经常作为过滤条件的字段作为排序索引，可提升相关查询的性能。以第一个排序索引为条件的搜索速度最快，后 2 个索引的查询速度依次递减。
• 建表成功后，排序索引 不支持修改类型/增列/减列 （若要修改需要删除表后重新回溯数据）

2. 分区键/粒度 （可选） Partition By #

• 定义与原理：分区是在一个表中通过指定的规则划分而成的逻辑数据集，可以按日或按月、按年进行分区。为了减少需要操作的数据，每个分区都是分文件存储的。访问数据时，ByteHouse 尽量使用这些分区的最小子集，以提升性能。
• 字段限制：分区字段不能支持 Nullable，支持设置 1-5 个字段。
• 分区粒度：当列的类型为 Date 时，支持天和月级别进行聚合分区；当列的类型为 Datetime 时，支持分钟、小时、天、和月级别进行聚合分区
• 配置建议：
  • 建议尽可能确保该字段的类型/内容为时间，其他非时间的内容会引起分区文件过多，严重影响导入效果和查询速度
  • 尽可能将分区字段配置为经常被筛选的日期字段，如订单时间等
  • 单天数据量 > 100亿才考虑按小时分区，否则建议选择默认按天分区
• 建表成功后，分区字段 不支持修改类型/增列/减列

3. 分桶键（可选） Cluster By #

• 定义与原理：当分区无法解决数据均匀分布的情况下，可以进一步利用分桶字段确保一列数据均匀分布在集群各节点下，可最大化利用集群性能进行查询。同时合理的设置分桶字段也有助于解决数据倾斜的问题，确保数据更加均匀地分布。
• 字段限制：分桶字段不能支持 Nullable
• 配置建议：一般选择取经常出现在 Group by 中的字段。
• 建表成功后，分桶字段不支持修改类型/修改字段

4. 数据保留时间 TTL （可选） #

• 定义与原理：设置数据生命周期，天级单位。数据保留时间是以“分区字段”作为基础进行计算。
• 字段限制：≥0。填写“0”时，表示不设置表的 TTL，即数据永久保留。
• 数据保留时间可以在建表后修改，一旦数据的时限超过保留时间，将会被自动删除。

5. 采样键 （可选） Sample Key #

• 定义与原理：用于在抽样查询中使用。这类查询只对特定部分数据（样本）执行查询。非常适合牺牲准确性以换取性能，或需求结果本身是近似值的查询。
• 字段限制：
  • 采样字段只支持UInt8，UInt16，UInt32，UInt64。
  • 无默认设置，如需执行采样键，必须建表加上Sample Key。
• 配置建议：若全表有抽样查询需求，且某字段数据分布均匀（如时间类字段），可设置为采样字段。
• 建表成功后，不支持修改。

6. 唯一键 （可选） Unique Key #

• 定义与原理：唯一键是 ByteHouse 团队自研的能力，既能保持高效的查询性能、又支持唯一键更新。主要解决了开源 ClickHouse 不能支持高效更新操作的痛点，帮助业务更简单地开发实时分析应用。用户通过指定唯一键 UNIQUE KEY 来实现 Upsert 更新写语义，查询自动返回每个唯一键的最新值。
• 字段限制：建议 Unique Key 字段设置不超过 5 个；如果多个字段组合构成唯一键，可以使用它们的 toString(sipHash128()) 哈希作为唯一键。目前支持三种粒度，即表级别、分区级和 bucket 级别唯一键。
• 更多唯一键的最佳实践和查询样例可以参考 ByteHouse Unique 表最佳实践。
• 建表成功后，不支持修改。

7. 主键（可选）Primary key #

• 定义与原理：主键是数据排序与查询加速的逻辑索引，而非传统意义上强制唯一性的约束标识。
• 配置建议：默认情况不需要显式指定，ByteHouse 将使用排序键作为主键。当有特殊场景主键和排序键不一致时，主键必须为排序键的最左前缀。如排序键为(OrderID, Date)，主键必须为 OrderID，不能为 Date。