openGauss

为了确保团队内以及团队之间可以快速顺利的进行工作交接，在最小的成本下理解已经存在的数据库对象。

• 规范需要持续维护，不断改善来适应自身业务的发展。
• 标准的规范可以减少出错的概率，保证程序安全稳定运行。
• 可以快速定位问题原因并有效解决。
• 标准的规范可以提升开发效率，也可自动化管理。

命名规范 ​

数据库对象（database, schema, table, column, view, index, function, trigger 等）命名标准：

• 长度不超过 63 个字符
• 命名尽量采用富有意义英文词汇
• 建议使用小写字母、数字、下划线的组合
• 不以 PG、GS 开头（避免与系统 DB object 混淆），不以数字开头
• 不使用双引号即"包围，除非必须包含大写字母或空格等特殊字符
• 禁止使用保留字，保留关键字参考官方文档或通过 pg_get_keywords() 函数查看
• table 能包含的 column 数目,根据字段类型的不同，数目在 250 到 1600 之间
• 分区表命令规则与普通表保持一致
• 临时或备份的数据库对象名，如 table,建议添加日期, 如 dba.trade_record_2100_01_07
• 索引显示命名规则为：表名_列名_idx，与缺省默认给出的索引名保持一致
• 数据库的用户表空间用 ts_<表空间名>来表现 ,数据表空间和索引表空间可以分开，如 ts_data_xxx 和 ts_idx_xxx

设计规范 ​

Tablespace 设计 ​

• 频繁使用的表和索引单独存放在一个表空间，此表空间应在性能好的磁盘上创建
• 以历史数据为主，或活跃度较低的表和索引可以存放在磁盘性能较差的表空间
• 表和索引可以单独存放在不同的表空间
• 表空间可以按数据库分、按 schema 分或按业务功能来分
• 也可以用默认表空间 pg_default，即 base 目录

Database 设计 ​

• 建议以业务功能来命名数据库，简单直观
• 推荐使用兼容 PG 模式创建数据库
• 数据库编码建议使用 UTF8

Schema 设计 ​

• 在一个数据库下执行创建用户时，默认会在该数据库下创建一个同名 schema
• 不建议在默认 public schema 下创建数据库对象
• 创建一个与用户名不同的 schema 给业务使用

Table 设计 ​

• 规划好表结构设计，避免添加字段、修改字段类型或长度
• 禁止使用 unlogged、temp/temporary 关键字创建业务表
• 必须为表添加 comment 注释信息
• 表间关联字段数据类型要保持一致，避免索引无法使用
• 对于频繁更新的 astore 表，需要指定填充因子 fillfactor=85，给 HOT 预留空间
• 频繁更新使用的表应该单独放在存储性能好的表空间
• 数据量超过亿级或占用磁盘超过 10GB 的表，建议考虑分区

Cloumn 设计 ​

• 避免与系统表的列名重复
• 字段含义及数据类型要与程序代码设计保持一致
• 所有字段必须要添加 comment 注释信息
• 能使用数值类型，就不要使用字符类型
• 禁止用字符类型存储日期数据
• 时间类型字段统一使用 timestamptz
• 字段尽量要求 not null，为字段提供默认值

Sequence 设计 ​

• 禁止手动创建与表相关的序列，应指定 serial/bigserial 类型方式创建
• 序列的步长建议设置为 1
• 不建议设置 minvalue 和 maxvalue
• 不建议设置 cache，设置 cache 后序列号不连续
• 禁止开启 cycle

Index 设计 ​

• 频繁 DML 操作的表索引数量不建议超过 5 个
• create/drop index 时添加 concurrently 参数
• 真正创建索引前可以使用虚拟索引确定索引的有效性
• 经常出现在关键字 order by、group by、distinct 后面的字段，建立索引
• 经常用作查询选择的字段，建立索引
• 经常用作表连接的属性上，建立索引
• 复合索引的字段数不建议超过 3 个
• 复合索引得一个字段是常用检索条件
• 复合索引第一个字段不应存在单字段索引
• 用 unique index 替换 unique constraints
• 对数据很少被更新的表，经常只查询其中的几个字段，考虑使用索引覆盖
• 不要在有大量相同取值的字段上建立索引

Partition Table 设计 ​

• 范围分区表数量不建议超过 1000 个
• 分区表可以按使用频度选择表空间
• 分区键必须要有索引，不建议使用全局索引
• 定期清理历史分区表

View 设计 ​

• 尽量使用简单视图，减少复杂视图（数据来自多个表，表的数量不建议超过 3 个）
• 避免嵌套视图，如必须使用，不能嵌套 2 层

Constraint 设计 ​

• 每张表必须要有主键
• 不要用有业务含义的字段做主键，尽管其唯一
• 建议使用 id serial/bigserial primary key 的方式创建主键
• 大表添加主键可以使用 unique + not null 的方式替代
• 建议使用唯一索引替换唯一约束
• 所有非空列必须要添加 not null 约束
• 存在外键关系的表尽量添加外键约束
• 性能要求高而安全性自己控制的系统不建议使用外键

操作规范 ​

DDL 操作 ​

• 业务高峰期禁止对已存在的表执行任何 DDL 操作
• 所有生产 DDL 操作必须经过开发测试环境验证
• 大表添加带默认值的字段时，应拆分为：添加字段、填补默认值及添加非空约束三部分
• 维护索引时应采用 concurrently 的方式
• 应该使用 pg_repack 替换 vacuum full 来重建表

DML 操作 ​

• 更新数据的 SQL 语句禁止出现 where 1=1
• 单条 DML 语句操作的数据量不超过 10 万
• 清空表中的数据时，应使用 truncate
• 对于风险性较高的操作，应该显示的开启事务，确认无误后在提交
• 事务中 SQL 逻辑尽量简单，操作执行完后要及时提交，避免 idle in transaction 状态
• 大批数据入库时应使用 copy 替换 insert
• 数据导入前考虑先删除索引，导入完成后重建

DQL 操作 ​

• 禁止使用 select * ，应用具体所需字段替换
• 禁止使用 where 1=1 ，避免全表扫描或笛卡尔积
• 检索条件值应该与字段类型保持一致，防止不走索引
• 等号左边的字段应该与索引保持一致，尤其是条件索引或函数索引
• 关注慢 SQL 的执行计划，如与预期不一致，尽快修改
• 使用 count(*) 或 count(1) 来统计行数， count(column) 不会统计 null 行
• 限制 join 的数量，不建议超过 3 个
• 递归查询需要做好限制，防止无限循环
• 对于 or 运算，应该使用 union all 或 union 替换