暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

openGauss训练营学习心得--开发规范

原创 小文子 2022-05-17
506

       在通过训练营的学习,开发与运维这部分知识还是比较容易理解的,与其它数据库都大同小异。现将课堂上老师讲的对象命名规范和数据库日常操作规范整理出来,以备日后工作和学习中快速找到使用。

       在开发过程中,需要特别注意这些对象的设计使用规范、命名规范、操作规范等,有了统一明确的规范之后,才能提高开发效率和使用便捷性。openGauss数据库对象包括:database, schema, table, column, view, index, function,trigger,sequence等。相关规范整理如下:


命名规范:

• 长度不超过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 替换

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论