规范设计 配置中心 流程设计 主题设计 码表管理 数据标准 关系建模 业务指标 技术指标 维度建模 父主题： 实施步骤

查看更多 →

。 用户新建立的表空间必须采用本地管理和自动段空间管理。 没有必要频繁的整理表空间中的碎片，除非碎片率达到了80%以上。 如果表空间因频繁的DDL操作出现碎片，建议设置表空间的UNIFORM SIZE为合适的数值（例如1MB），来减少碎片的产生。 索引设计原则 表的主键、外键必须有索引；

查看更多 →

段上查询会返回较大的结果集。尽量避免返回较大的结果集。 对集合的写操作同时会操作集合上的索引，从而触发更多的IO操作，集合上的索引数量不要超过32。 不要创建不会被使用到的索引，因为DDS会加载索引到内存，无用索引加载到内存会浪费内存空间因业务逻辑变化而产生的无用索引也要及时清理。

查看更多 →

段上查询会返回较大的结果集。尽量避免返回较大的结果集。 对集合的写操作同时会操作集合上的索引，从而触发更多的IO操作，集合上的索引数量不要超过32。 不要创建不会被使用到的索引，因为DDS会加载索引到内存，无用索引加载到内存会浪费内存空间因业务逻辑变化而产生的无用索引也要及时清理。

查看更多 →

权限设计规范 业务使用前必须由root用户为业务创建DATABASE、SCHEMA和USER，然后再赋予相关用户对应对象的权限。 如果该用户不是该schema的owner，要访问schema下的对象，需要同时给用户赋予schema的usage权限和对象的相应权限。 DATABASE、SCHEMA和USER名使用小写。

查看更多 →

索引列为表的一列或多列计算而来的一个函数或者标量表达式 限制使用 对于HASH分布表，主键和唯一索引必须包含分布键。 当设计组合索引时，优化器会通过计算代价来选择合适的执行计划。例如：在组合索引(a,b,c)下，当查询时如果只使用过滤条件b，优化器经过计算索引成本较低时，会选择索引。

查看更多 →

选择无需检查接口，单击“确定”，完成添加。 快捷搜索 可输入关键字快捷查找已存在的设计规范。 设计规范定义更新 单击“管理”，可以修改设计规范中启用的设计规则。 单击“编辑”，可以修改设计规范的名称和描述。 设计规范删除 单击“删除”，可以删除设计规范。 父主题： 项目设置

查看更多 →

上分别建立唯一索引。 即使在应用层做了完善的校验控制，只要没有唯一索引，根据墨菲定律，必然有脏数据产生。 同时需要考虑建立的唯一索引对查询是否真正有帮助，没有帮助的索引可以考虑删除； 需要考虑多建立的索引对插入性能的影响，根据唯一性相关的数据正确性需求，以及性能需求来权衡是不是需要多建立唯一性索引。

查看更多 →

，减少DN间数据的流动代价。 尽量避免数据shuffle。shuffle，是指在物理上，数据从一个节点，传输到另一个节点。shuffle占用了大量宝贵的网络资源，减小不必要的数据shuffle，可以减少网络压力，使数据的处理本地化，提高集群的性能和可支持的并发度。通过对关联条件和

查看更多 →

该节点的其他请求，导致业务成功率下降。诸如此类的还有热门商品促销，网红直播等场景，这些典型的读多写少的场景也会产生热点问题。 如何处理大key和热key问题请参见如何检测和解决大key与热key问题。 另外，对GeminiDB Cassandra数据库的读能力有更高要求的，读多写

查看更多 →

ClickHouse设计开发规范 ClickHouse设计规范概述 ClickHouse集群规划 ClickHouse数据库设计 ClickHouse数据库开发 ClickHouse数据库调优 ClickHouse数据库运维

查看更多 →

库表设计规范 所有创建的MySQL表必须为InnoDB引擎，适配MySQL的其它引擎不支持事务。 小数类型建议使用DECIMAL，禁止使用FLOAT和DOUBLE。 FLOAT和DOUBLE在存储的时候，存在精度损失的问题，很可能在值比较的时候得到的结果有误。如果存储的数据范围超

查看更多 →

如果对存储在字符类型字段中的数据进行数值计算，或者与数值进行比较操作（如置于过滤条件中），会带来不必要的数据类型转换的开销，同时该字段上的索引可能失效，影响查询性能。 字符类型字段不应存储时间或日期类数据。 如果对存储在字符类型字段中的数据与日期类数据进行计算或比较操作（如置于过滤

查看更多 →

SparkSQL天然与Hive集成，无需考虑元数据问题。该条建议针对的是通过Spark Datasource API或者Flin写Hudi表的场景，通过这两种方式写Hudi时需要增加向Hive同步元数据的配置项；该配置的目的是将Hudi表的元数据统一托管到Hive元数据服务中，为后续的跨引擎操作数据以及数据管理提供便利。

查看更多 →

（车牌号1，车牌号3），（通过的第1个收费站，通过的第2个收费站） 根据通过相同收费站的两辆车的车牌号聚合数据，如下： （车牌号1，车牌号2），[（通过的第1个收费站，通过的第5个收费站），（通过的第2个收费站，通过的第6个收费站），（通过的第1个收费站，通过的第7个收费站），（通过的第3个收费站，通过的第8个收费站）]

查看更多 →

数据库设计规范 基本规范 部署规范 数据库对象命名规范 数据库设计规范 权限设计规范 表设计规范 字段设计规范 索引设计规范 函数/存储过程设计规范 父主题： 使用规范建议

查看更多 →

S)的分布式处理架构，输出更高效的业务SQL代码。 对业务的执行效率不满意，期望通过调优加快业务执行的情况下，可以参考优化查询性能进行调优。性能调优是一项复杂的工程，有些时候无法系统性地说明和解释，而是依赖于DBA的经验判断。尽管如此，优化查询性能一节还是期望能尽量系统性的对性能

查看更多 →

S)的分布式处理架构，输出更高效的业务SQL代码。 对业务的执行效率不满意，期望通过调优加快业务执行的情况下，可以参考优化查询性能进行调优。性能调优是一项复杂的工程，有些时候无法系统性地说明和解释，而是依赖于DBA的经验判断。尽管如此，优化查询性能章节还是期望能尽量系统性的对性能

查看更多 →

基于简化使用的角度，针对大数据量的表，可以通过采用Bucket索引来避免状态后端的复杂调优。 如果Bucket索引+分区表的模式无法平衡Bueckt桶过大的问题，还是可以继续采用Flink状态索引，按照规范去优化对应的配置参数即可。 建议 基于Flink的流式写入的表，在数据量超

查看更多 →

ClickHouse设计规范概述 内容介绍 本文主要描述ClickHouse数据管理全生命周期过程中，数据库规划、建模设计、开发、调优、运维的规则建议和指导。 通过这些约束和建议，指导开发者在ClickHouse数据库开发使用过程中能够最大化发挥数据库的优势，保障ClickHou

查看更多 →

有一定时间范围规律的，比如：近一个月的数据更新占比最大，可以按照月份创建分区；近一天内的数据更新占比大，可以按照天进行分区。 采用Bucket索引，写入是通过主键Hash打散的，数据会均匀的写入到分区下每个桶。因为各个分区的数据量是会有波动的，分区下桶的个数设计一般会按照最大分区

查看更多 →