GaussDB(DWS)总体开发设计规范

用户和连接管理

1

尽量避免所有业务使用同一个数据库用户运行，按业务模块规划不同数据库用户。

注意

异常业务或用户操作导致整体集群问题时，无法快速隔离和管控。

2

不建议使用系统管理员用户跑业务，不同模块业务请通过多用户和权限进行访问控制。

注意

管理员用户权限过高，难以管控。

3

不建议业务直连单CN，需配置负载均衡保证各CN连接均衡。

警告

CN上连接不均、负载倾斜，拖慢整体性能。

4

连接数据库完成所需操作后，要及时关闭数据库连接，避免空闲连接持续占位，消耗连接和公共资源。

警告

空闲连接过多，消耗大量公共资源，正常业务无法建立连接和运行。

5

使用数据库连接池的场景，在业务中通过SET语句进行数据库GUC参数设置后，归还连接池前必须通过RESET还原参数设置。

警告

使用连接池的作业之间互相干扰。

对象设计

6

不建议创建普通表时指定自定义TABLESPACE。

警告

自定义表空间所占存储空间不受管控，会导致空间和性能类问题。

7

创建行存表时应避免指定COMPRESS压缩属性。

警告

行存压缩功能不稳定，后续已废弃。

8

针对普通列存表不建议频繁进行小批量实时入库。

警告

列存实时入库导致小CU膨胀严重，触发持续的空间、资源、性能类问题。

9

创建HASH分布的表对象时，要确保数据分布均匀（10G以上数据量的表，倾斜率控制在10%以内）。

警告

数据分布倾斜，进而导致计算倾斜，导致空间和性能类问题。

10

创建REPLICATION分布的表对象，要确保表数据量控制在100万行以内。

注意

复制表数据量过大会导致存储空间增长风险。

11

创建HSTORE表时，必须确保数据库GUC参数设置满足以下条件：

• autovacuum设置为on。
• autovacuum_max_workers_hstore取值大于0。
• autovacuum_max_workers取值大于autovacuum_max_workers_hstore的取值。

警告

HSTORE的delta表急剧膨胀，性能持续下降。

12

针对存在时间字段的大表（数据量5000万行以上），必须设计成分区表，根据查询特征合理设计分区间隔。

警告

针对分区表进行特定时间段的查询、清理效率远高于非分区表。

13

针对有大批量数据增删改的表，索引个数建议控制在3个以内，最多不超过5个。

警告

索引过多影响增删改效率。

操作规范

14

客户端显式开启事务或手动关闭Autocommit场景，业务最后必须手动执行Commit提交事务。

警告

事务不提交导致长事务，阻塞其他持锁业务和回收操作。

15

针对执行时长超过30分钟的语句，建议优化。

注意

业务效率及性能问题。

16

尽量避免出现执行时长超过2小时的业务，避免长事务、长持锁等影响。

警告

业务性能，长事务阻塞其他持锁业务和回收操作。

17

DROP对象操作（如DATABASE、USER/ROLE、SCHEMA、TABLE、VIEW等对象）存在数据丢失风险，尤其含带CASCADE级联删除场景，会将关联的对象一并删除，操作需谨慎，操作前需考虑数据备份。

危险

数据被异常删除，无法快速恢复。

18

避免在业务高峰期执行ALTER（增删改列、DROP PARTITION等）、TRUNCATE操作，避免有长SQL阻塞ALTER、TRUNCATE操作或SQL业务被ALTER、TRUNCATE阻塞。

警告

ALTER、TRUNCATE持锁级别高，会阻塞其他也并发业务，也会被其他业务阻塞，造成业务卡问题。

19

避免在业务高峰期执行对大表执行CREATE INDEX和REINDEX操作。

警告

CREATE INDEX、REINDEX操作会阻塞数据入库，大表上执行耗时较长会长时间阻塞数据入库。

20

尽量避免出现计划不下推的SQL写法（EXPLAIN输出的执行计划中出现"_REMOTE_XXX_QUERY_"）。

警告

业务性能问题、CN瓶颈。

21

尽量避免行存大表（数据量1000万行以上）的频繁COUNT查询。

注意

业务性能问题、高IO资源消耗。

22

单SQL的UNION/UNION All分支不能超过50，多表关联不能超过25张非复制表。

警告

业务性能问题、高资源消耗。

23

尽量避免大表关联时缺少关联条件而求笛卡尔积。

警告

业务性能问题、高资源消耗。

24

多表关联查询时，单个语句Stream建议控制在100以内。

注意

业务性能问题、高CPU消耗。

25

谨慎使用递归语句(WITH RECURSIVE)，需明确数据重复度和终止条件，确保递归可按预期结束。

警告

业务性能问题、死循环。

26

避免使用UPDATE/DELETE大批量刷新和删除数据，考虑使用TRUNCATE PARTITION/DROP PARTITION代替。

注意

业务性能、脏页问题。

27

避免UPDATE/UPSERT并发更新同一张列存表。

警告

业务性能、锁问题。

28

尽量避免使用存储过程，尤其不要开发结构复杂、嵌套多层的存储过程。

注意

维护效率低、问题定位成本高。

运维管理

29

默认开启Autovacuum/Autoanalyze自动运维开关（8.1.3及以上版本支持）。

警告

对象膨胀、业务性能问题。

30

单次新增、修改量占表总量10%以上场景，需在业务中增加显式Analyze操作。

警告

业务性能稳定性问题。

31

定期对脏页率、小CU占比超过25%的表执行VACUUM FULL，普通表需在低峰期执行，系统表需离线执行。

警告

对象膨胀、业务性能问题。

32

数据库重要程度以上告警，需及时处理并消除告警。

警告

集群长期稳定性。

33

业务批量上线、上量前需在测试集群进行相当规模测试验证，并知会技术支持人员进行业务保障。

警告

业务上线评估、保障。