表设计 总体上讲，良好的表设计需要遵循以下原则： 减少需要扫描的数据量。通过分区表的剪枝机制可以大幅减少数据的扫描量。 尽量减少随机I/O。通过聚簇可以实现热数据的连续存储，将随机I/O转换为连续I/O，从而减少扫描的I/O代价。 选择分区方案 当表中的数据量很大时，应当对表进行分区，一般需要遵循以下原则：

查看更多 →

le占用了大量宝贵的网络资源，减少不必要的数据shuffle，可以减少网络压力，使数据的处理本地化，以提高集群的性能和可支持的并发度。通过对关联条件和分组条件的仔细设计，能够尽可能的减少不必要的数据shuffle。 选择分布方案 表的分布方式的选择如表2 表的分布方式及使用场景所示。

查看更多 →

表设计 总体上讲，良好的表设计需要遵循以下原则： 减少需要扫描的数据量。通过分区表的剪枝机制可以大幅减少数据的扫描量。 尽量减少随机I/O。通过聚簇可以实现热数据的连续存储，将随机I/O转换为连续I/O，从而减少扫描的I/O代价。 选择分区方案 当表中的数据量很大时，应当对表进行分区，一般需要遵循以下原则：

查看更多 →

避免使用分区表，如有需要，可以使用多个独立的表代替。 分区表的缺点： DDL操作需要锁定所有分区，导致所有分区上操作都被阻塞。 当表数据量较大时，对分区表进行DDL或其他运维操作难度大风险高。 分区表使用较少，存在未知风险。 当单台 服务器 性能无法满足时，对分区表进行分拆的成本较高。

查看更多 →

联条件和分组条件的仔细设计，能够尽可能的减少不必要的数据shuffle。 选择存储方案 【建议】表的存储类型是表定义设计的第一步，客户业务类型是决定表的存储类型的主要因素，表存储类型的选择依据请参考表1。 表1 表的存储类型及场景 存储类型 适用场景 行存 点查询(返回记录少，基于索引的简单查询)。

查看更多 →

用了大量宝贵的网络资源，减少不必要的数据shuffle，可以减少网络压力，使数据的处理本地化，以提高集群的性能和可支持的并发度。通过对关联条件和分组条件的仔细设计，能够尽可能的减少不必要的数据shuffle。 选择分布方案 表的分布方式的选择如表1所示。 表1 表的分布方式及使用场景

查看更多 →

【建议】表的存储类型是表定义设计的第一步，客户业务类型是决定表的存储类型的主要因素，表存储类型的选择依据请参考表1。 表1 表的存储类型及场景 存储类型 适用场景 行存 点查询（返回记录少，基于索引的简单查询）。 增、删、改操作较多的场景。 选择分区方案 当表中的数据量很大时，应当对表进行分区，一般需要遵循以下原则：

查看更多 →

业务需要设置分析报表的分类，便于日后按分类查找报表。 图3 账表分类 在账表分类上新建报表，设置报表编码、名称等信息。 图4 新建账表 新建报表后报表是没有样式的，还需要针对新建的报表设计该报表的格式。设计格式之初，首先选择合适的数据模型，然后进行报表格式设计。 图5 数据模型选择

查看更多 →

表设计最佳实践 使用分区表 选择数据类型 父主题： 最佳实践

查看更多 →

表设计最佳实践 选择分布方式 选择分布列 使用分区表 选择数据类型 查看表所在节点 父主题： 最佳实践

查看更多 →

ref：哪些列或常量被用于查找索引列上的值。 rows：根据表统计信息及索引选用情况，估算的找到所需的记录所需要读取的行数。 Extra： Using temporary：表示MySQL需要使用临时表来存储结果集，常见于排序和分组查询。 Using filesort：MySQL中无法利用索引完成的排序操作称为“文件排序”。

查看更多 →

表设计最佳实践 选择存储模型 使用分区表 选择数据类型 父主题： 最佳实践

查看更多 →

表设计最佳实践 选择存储模型 选择分布方式 选择分布列 使用分区表 选择数据类型 查看表所在节点 父主题： 最佳实践

查看更多 →

照数据库的最左匹配原则分布。为避免产生写入热点问题，建议您遵循以下条件： 主键的第一列尽量分散，不建议主键名使用相同的前缀。 避免使用共同前缀或者自增的数据作为主键的第一列或者索引列（例如时间戳列）。 避免使用有明显前缀的字段或者枚举（比如order_type）作为主键的第一列。

查看更多 →

ClickHouse宽表设计 ClickHouse宽表设计原则 ClickHouse表字段设计 ClickHouse本地表设计 ClickHouse分布式表设计 ClickHouse分区设计 ClickHouse索引设计 父主题： ClickHouse应用开发规范

查看更多 →

化，提高集群的性能和可支持的并发度。通过对关联条件和分组条件的仔细设计，能够尽可能的减少不必要的数据shuffle。 选择存储方案 【建议】表的存储类型是表定义设计的第一步，用户业务类型是决定表的存储类型的主要因素，表存储类型的选择依据请参考表1。 表1 表的存储类型及场景 存储模型

查看更多 →

化，提高集群的性能和可支持的并发度。通过对关联条件和分组条件的仔细设计，能够尽可能的减少不必要的数据shuffle。 选择存储方案 【建议】表的存储类型是表定义设计的第一步，用户业务类型是决定表的存储类型的主要因素，表存储类型的选择依据请参考表1。 表1 表的存储类型及场景 存储类型

查看更多 →

流式计算采用MOR表。 流式计算为低时延的实时计算，需要高性能的流式读写能力，在Hudi表中存在的MOR和COW两种模型中，MOR表的流式读写性能相对较好，因此在流式计算场景下采用MOR表模型。关于MOR表在读写性能的对比关系如下： 对比维度 MOR表 COW表 流式写 高 低 流式读

查看更多 →

视图和关联表设计 视图设计 【建议】除非视图之间存在强依赖关系，否则不建议视图嵌套。 【建议】视图定义中尽量避免排序操作。 关联表设计 【建议】表之间的关联字段应该尽量少。 【建议】关联字段的数据类型应该保持一致。 【建议】关联字段在命名上，应该可以明显体现出关联关系。例如，采用同样名称来命名。

查看更多 →

ClickHouse宽表设计原则 宽表设计原则 由于ClickHouse的宽表查询性能较优，且当前ClickHouse可支持上万列的宽表横向扩展。 在大部分场景下，有大表两表join以及多表join的场景，且多个join的表数据变化更新频率较低，这种情况，建议对多个表join查询逻辑提

查看更多 →

ClickHouse本地表设计 规则 单表（分布式表）的记录数不要超过万亿，对于万亿以上表的查询，性能较差，且集群维护难度变大。单表（本地表）不超过百亿。 表的设计都要考虑到数据的生命周期管理，需要进行TTL表属性设置或定期老化清理表分区数据。 单表的字段建议不要超过5000列。

查看更多 →