云服务器内容精选

  • DDL 【建议】在GaussDB中,建议DDL(建表、comments等)操作统一执行,在批处理作业中尽量避免DDL操作。避免大量并发事务对性能的影响。 【建议】在非日志表(unlogged table)使用完后,立即执行数据清理(truncate)操作。因为在异常场景下,GaussDB不保证非日志表(unlogged table)数据的安全性。 【建议】临时表和非日志表的存储方式建议和基表相同。当基表为行存(列存)表时,临时表和非日志表也推荐创建为行存(列存)表,可以避免行列混合关联带来的高计算代价。 【建议】索引字段的总长度不超过50字节。否则,索引大小会膨胀比较严重,带来较大的存储开销,同时索引性能也会下降。 【建议】不要使用DROP…CASCADE方式删除对象,除非已经明确对象间的依赖关系,以免误删。
  • 数据加载和卸载 【建议】在insert语句中显式给出插入的字段列表。例如: 1 INSERT INTO task(name,id,comment) VALUES ('task1','100','第100个任务'); 【建议】在批量数据入库之后,或者数据增量达到一定阈值后,建议对表进行analyze操作,防止统计信息不准确而导致的执行计划劣化。 【建议】如果要清理表中的所有数据,建议使用truncate table方式,不要使用delete table方式。delete table方式删除性能差,且不会释放那些已经删除了的数据占用的磁盘空间。
  • 数据加载和卸载 【建议】在insert语句中显式给出插入的字段列表。例如: 1 INSERT INTO task(name,id,comment) VALUES ('task1','100','第100个任务'); 【建议】在批量数据入库之后,或者数据增量达到一定阈值后,建议对表进行analyze操作,防止统计信息不准确而导致的执行计划劣化。 【建议】如果要清理表中的所有数据,建议使用truncate table方式,不要使用delete table方式。delete table方式删除性能差,且不会释放那些已经删除了的数据占用的磁盘空间。
  • DDL 【建议】在GaussDB中,建议DDL(建表、comments等)操作统一执行,在批处理作业中尽量避免DDL操作。避免大量并发事务对性能的影响。 【建议】在非日志表(unlogged table)使用完后,立即执行数据清理(truncate)操作。因为在异常场景下,GaussDB不保证非日志表(unlogged table)数据的安全性。 【建议】临时表和非日志表的存储方式建议和基表相同。当基表为行存(列存)表时,临时表和非日志表也推荐创建为行存(列存)表,可以避免行列混合关联带来的高计算代价。 【建议】索引字段的总长度不超过50字节。否则,索引大小会膨胀比较严重,带来较大的存储开销,同时索引性能也会下降。 【建议】不要使用DROP…CASCADE方式删除对象,除非已经明确对象间的依赖关系,以免误删。
  • 数据库对象命名 数据库对象命名需要满足约束: 标识符表长度不超过63个字节。 标识符以字母或下划线开头,中间字符可以是字母、数字、下划线、$、#。 若标识符被双引号("")包含,则可以使用合法字符的任意组合,如"123gs_column"。 标识符不区分大小写,只有被双引号包含才区分大小写。 避免使用保留或者非保留关键字命名数据库对象。 可以使用select * from pg_get_keywords()查询GaussDB的关键字,或者在关键字章节中查看。 避免使用双引号括起来的字符串来定义数据库对象名称,除非需要限制数据库对象名称的大小写。数据库对象名称大小写敏感会使定位问题难度增加。 数据库对象命名风格务必保持统一。 增量开发的业务系统或进行业务迁移的系统,建议遵守历史的命名风格。 建议使用多个单词组成,以下划线分割。 数据库对象名称建议能够望文知意,尽量避免使用自定义缩写(可以使用通用的术语缩写进行命名)。例如,在命名中可以使用具有实际业务含义的英文词汇或汉语拼音,但规则应该在集群范围内保持一致。 变量名的关键是要具有描述性,即变量名要有一定的意义,变量名要有前缀标明该变量的类型。 表对象的命名应该可以表征该表的重要特征。例如,在表对象命名时区分该表是普通表、临时表还是非日志表: 普通表名按照数据集的业务含义命名。 临时表以“tmp_+后缀”命名。 非日志表以“ul_+后缀”命名。 外表以“f_+后缀”命名。 不创建以redis_为前缀的数据库对象。 不创建以mlog_和以matviewmap_为前缀的数据库对象。 不创建以gs_role_为前缀的数据库对象。 表对象命名建议不要超过63字节。如果超过该长度内核会对表名进行截断,从而出现实际名称和设置值不一致的现象,且在不同字符集下,可能造成字符被截断,出现预期外的字符。 父主题: 开发设计建议
  • DDL 在GaussDB中,建议DDL(建表、COMMENT等)操作统一执行。在批处理作业中尽量避免DDL操作,避免大量并发事务对性能的影响。 在非日志表(unlogged table)使用完后,立即执行数据清理(TRUNCATE)操作。因为在异常场景下,GaussDB不保证非日志表(unlogged table)数据的安全性。 临时表和非日志表的存储方式建议和基表相同。 索引字段的总长度不超过50字节。否则,索引大小会膨胀比较严重,带来较大的存储开销,同时索引性能也会下降。 不要使用DROP…CASCADE方式删除对象,除非已经明确对象间的依赖关系,以免误删。
  • 数据加载和卸载 在INSERT语句中显式设置插入的字段列表。例如: 1 INSERT INTO task(name,id,comment) VALUES ('task1','100','第100个任务'); 在批量数据入库之后,或者数据增量达到一定阈值后,建议对表进行ANALYZE操作,防止统计信息不准确而导致的执行计划劣化。 如果要清理表中的所有数据,建议使用TRUNCATE TABLE方式,不要使用DELETE TABLE方式。DELETE TABLE方式删除性能差,且不会释放那些已经删除了的数据占用的磁盘空间。
  • 开发设计建议概述 开发设计建议约定数据库建模和数据库应用程序开发过程中,应当遵守的设计规范。依据这些规范进行建模,能够更好地契合GaussDB的处理架构,输出更高效的业务SQL代码。 开发设计建议中所陈述的“建议”和“关注”含义如下: 建议:用户应当遵守的设计规则。遵守这些规则,能够保证业务的高效运行;违反这些规则,将导致业务性能的大幅下降或某些业务逻辑错误。 关注:在业务开发过程中用户需要注意的细则。用于标识容易导致用户理解错误的知识点(实际上遵守SQL标准的SQL行为),或者程序中潜在的用户不易感知的默认行为。 父主题: 开发设计建议
  • 开发设计建议概述 开发设计建议约定数据库建模和数据库应用程序开发过程中,应当遵守的设计规范。依据这些规范进行建模,能够更好地契合GaussDB的分布式处理架构,输出更高效的业务SQL代码。 开发设计建议中所陈述的“建议”和“关注”含义如下: 建议:用户应当遵守的设计规则。遵守这些规则,能够保证业务的高效运行;违反这些规则,将导致业务性能的大幅下降或某些业务逻辑错误。 关注:在业务开发过程中用户需要注意的细则。用于标识容易导致用户理解错误的知识点(实际上遵守SQL标准的SQL行为),或者程序中潜在的用户不易感知的默认行为。 父主题: 开发设计建议
  • 数据库对象命名 数据库对象命名需要满足约束: 标识符表长度不超过63个字节。 标识符以字母或下划线开头,中间字符可以是字母、数字、下划线、$、#。 若标识符被双引号("")包含,则可以使用合法字符的任意组合,如"123gs_column"。 标识符不区分大小写,只有被双引号包含才区分大小写。 避免使用保留或者非保留关键字命名数据库对象。 可以使用select * from pg_get_keywords()查询GaussDB的关键字,或者在关键字章节中查看。 避免使用双引号括起来的字符串来定义数据库对象名称,除非需要限制数据库对象名称的大小写。数据库对象名称大小写敏感会使定位问题难度增加。 数据库对象命名风格务必保持统一。 增量开发的业务系统或进行业务迁移的系统,建议遵守历史的命名风格。 建议使用多个单词组成,以下划线分割。 数据库对象名称建议能够望文知意,尽量避免使用自定义缩写(可以使用通用的术语缩写进行命名)。例如,在命名中可以使用具有实际业务含义的英文词汇或汉语拼音,但规则应该在数据库实例范围内保持一致。 变量名的关键是要具有描述性,即变量名要有一定的意义,变量名要有前缀标明该变量的类型。 表对象的命名应该可以表征该表的重要特征。例如,在表对象命名时区分该表是普通表、临时表还是非日志表: 普通表名按照数据集的业务含义命名。 临时表以“tmp_+后缀”命名。 非日志表以“ul_+后缀”命名。 外表以“f_+后缀”命名。 不创建以redis_为前缀的数据库对象。 不创建以mlog_和以matviewmap_为前缀的数据库对象。 不创建以gs_role_为前缀的数据库对象。 表对象命名建议不要超过63字节。如果超过该长度内核会对表名进行截断,从而造成和设置值不一致的现象,且在不同字符集下,可能造成字符被截断,出现预期外的字符。 父主题: 开发设计建议
  • 数据加载和卸载 在INSERT语句中显式设置插入的字段列表。例如: 1 INSERT INTO task(name,id,comment) VALUES ('task1','100','第100个任务'); 在批量数据入库之后,或者数据增量达到一定阈值后,建议对表进行ANALYZE操作,防止统计信息不准确而导致的执行计划劣化。 如果要清理表中的所有数据,建议使用TRUNCATE TABLE方式,不要使用DELETE TABLE方式。DELETE TABLE方式删除性能差,且不会释放那些已经删除了的数据占用的磁盘空间。
  • DDL 在GaussDB中,建议DDL(建表、COMMENT等)操作统一执行。在批处理作业中尽量避免DDL操作,避免大量并发事务对性能的影响。 在非日志表(unlogged table)使用完后,立即执行数据清理(TRUNCATE)操作。因为在异常场景下,GaussDB不保证非日志表(unlogged table)数据的安全性。 临时表和非日志表的存储方式建议和基表相同。 索引字段的总长度不超过50字节。否则,索引大小会膨胀比较严重,带来较大的存储开销,同时索引性能也会下降。 不要使用DROP…CASCADE方式删除对象,除非已经明确对象间的依赖关系,以免误删。
  • 自定义外部函数(pgSQL/Java)使用 【关注】Java UDF可以实现一些java逻辑计算,禁止在Java UDF中封装业务。 【关注】禁止在Java函数中使用任何方式连接数据库,包括但不限于JDBC。 【关注】只能选择下表中的数据类型,不支持自定义类型、复杂数据类型(Java Array类及派生类)等: 【关注】不支持UDAF(用户定义聚合函数)、UDTF(用户自定义表生成函数)。 表1 PL/Java默认数据类型映射关系 GaussDB(DWS) Java BOOLEAN boolean "char" byte bytea byte[] SMALLINT short INTEGER int BIGINT long FLOAT4 float FLOAT8 double CHAR java.lang.String VARCHAR java.lang.String TEXT java.lang.String name java.lang.String DATE java.sql.Timestamp TIME java.sql.Time (stored value treated as local time) TIMETZ java.sql.Time TIMESTAMP java.sql.Timestamp TIMESTAMPTZ java.sql.Timestamp 父主题: 开发设计建议
  • 开发设计建议概述 本开发设计建议约定数据库建模和数据库应用程序开发过程中,应当遵守的设计规范。依据这些规范进行建模,能够更好的契合GaussDB(DWS)的分布式处理架构,输出更高效的业务SQL代码。 本开发设计建议中所陈述的“建议”和“关注”含义如下: 建议:用户应当遵守的设计规则。遵守这些规则,能够保证业务的高效运行;违反这些规则,将导致业务性能的大幅下降或某些业务逻辑错误。 关注:在业务开发过程中客户需要注意的细则。用于标识容易导致客户理解错误的知识点(实际上遵守SQL标准的SQL行为),或者程序中潜在的客户不易感知的默认行为。 父主题: 开发设计建议
  • DDL 【建议】在GaussDB中,建议DDL(建表、comments等)操作统一执行,在批处理作业中尽量避免DDL操作。避免大量并发事务对性能的影响。 【建议】在非日志表(unlogged table)使用完后,立即执行数据清理(truncate)操作。因为在异常场景下,GaussDB不保证非日志表(unlogged table)数据的安全性。 【建议】临时表和非日志表的存储方式建议和基表相同。当基表为行存(列存)表时,临时表和非日志表也推荐创建为行存(列存)表,可以避免行列混合关联带来的高计算代价。 【建议】索引字段的总长度不超过50字节。否则,索引大小会膨胀比较严重,带来较大的存储开销,同时索引性能也会下降。 【建议】不要使用DROP…CASCADE方式删除对象,除非已经明确对象间的依赖关系,以免误删。