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

查看更多 →

。 用户新建立的表空间必须采用本地管理和自动段空间管理。 没有必要频繁的整理表空间中的碎片，除非碎片率达到了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，优化器经过计算索引成本较低时，会选择索引。

查看更多 →

点新闻进行上万次的点击浏览和评论时，会形成一个较大的请求量，这种情况下会造成短时间内对同一个key频繁操作，会导致key所在节点的CPU和负载升高，从而影响落在该节点的其他请求，导致业务成功率下降。诸如此类的还有热门商品促销，网红直播等场景，这些典型的读多写少的场景也会产生热点问题。

查看更多 →

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

查看更多 →

分组条件的仔细设计，能够尽可能的减少不必要的数据shuffle。 由于数据库规格要求HASH分布表的主键必须包含其分布列，因此在选择分布列时，也可以考虑选择表的主键作为分布键。 表1 常见的分布键及效果 分布键值 分布键分布均匀性 用户 ID，应用程序中有许多用户。 好 状态代码，只有几个可用的状态代码。

查看更多 →

索引设计规范 避免因为字段类型不同造成的隐式转换，导致索引失效。 业务上具有唯一特性的字段，即使是多个字段的组合，建议在所有具有唯一特性字段的最小集合上建立唯一索引。 例如：一个表含有有a，b，c，d，e，f字段，在业务上ab和ef分别是具有唯一特性的字段集合，那么最好在最小集合ab和ef上分别建立唯一索引。

查看更多 →

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个收费站）]

查看更多 →

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

查看更多 →

户可更专注于上层业务，释放数据更大的价值。 表1 ClickHouse设计规范说明 项目 描述 数据库规划 集群业务规划、容量规划、数据分布。 数据库设计 Database设计、宽表设计、分布式表设计、本地表设计、分区设计、索引设计、物化视图设计。 数据库开发 简单查询、聚合查询

查看更多 →

月份创建分区；近一天内的数据更新占比大，可以按照天进行分区。 采用Bucket索引，写入是通过主键Hash打散的，数据会均匀的写入到分区下每个桶。因为各个分区的数据量是会有波动的，分区下桶的个数设计一般会按照最大分区数据量计算，这样会出现越细粒度的分区，桶的个数会冗余越多。例如：

查看更多 →

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

查看更多 →

绝大多数的字符，因此推荐使用UTF8。 GaussDB 中的UTF8字符集与MySQL数据库的UTF8MB4等价，能够支持emoji表情字符。 如果客户端的编码方式与数据库的编码方式不统一，需要转码，会带来性能问题，同时，针对同编码的内核优化无法触发，影响查询效率。 客户端的编码字符集需通过以下方式修改：

查看更多 →