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

为有效提升数据开发效率、降低资源消耗、减少业务阻塞，在使用GaussDB(DWS)进行数据开发之前，开发设计应遵循表1列举的开发设计规范。

本设计规范分为注意、警告、危险3个等级，各等级含义如下：

注意：建议用户遵守的设计规范。如果不遵守，可能会影响业务性能、增加运维难度。
警告：遵守这些规则，能够保证业务的高效运行；违反这些规则，可能导致业务阻塞、业务报错。
危险：违反这些规则，可能会造成数据误删、或导致系统重大变更甚至故障。

表1 总体开发设计规范
场景	序号	规范	等级	不遵守规范带来的影响
用户和连接管理	1	尽量避免所有业务使用同一个数据库用户运行，按业务模块规划不同数据库用户。	注意	异常业务或用户操作导致整体集群问题时，无法快速隔离和管控。
	2	不建议使用系统管理员用户跑业务，不同模块业务请通过多用户和权限进行访问控制。	注意	管理员用户权限过高，难以管控。
	3	不建议业务直连单CN，需配置负载均衡保证各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个。	建议	索引过多影响增删改效率，严重时还会导致xlog堆积和集群故障。
操作规范	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	集群级的数据库参数调整为变更操作，建议联系华为方进行变更风险评估	危险	集群级参数调整可能对客户业务造成影响，需做好评估。
	30	单次新增、修改量占表总量10%以上场景，需在业务中增加显式ANALYZE操作。	警告	业务性能稳定性问题。
	31	定期对脏页率、小CU占比超过25%的表执行VACUUM FULL，普通表需在低峰期执行，系统表需离线执行。	警告	对象膨胀、业务性能问题。
	32	数据库重要程度以上告警，需及时处理并消除告警。	警告	集群长期稳定性。
	33	业务批量上线、上量前需在测试集群进行相当规模测试验证，并知会技术支持人员进行业务保障。	注意	业务上线评估、保障。