云服务器内容精选

  • 总体开发设计规范 下表是 GaussDB (DWS)开发过程中需遵循的开发设计规范全集列表,可以单击链接跳转到对应的规则下了解详细说明。 表1 GaussDB(DWS)开发设计规范全集列表 编号 类别 规则/建议 1 连接管理规范 - 规则1.1 GaussDB(DWS)集群必须配置负载均衡 2 规则1.2 连接数据库完成所需操作后,必须关闭数据库连接(连接池场景除外) 3 规则1.3 开启的事务最后必须提交或回滚 4 规则1.4 应用侧使用连接池场景,其空闲超时配置必须小于服务侧的SESSION_TIMEOUT配置 5 规则1.5 应用侧使用连接池场景,如使用连接SET设置过参数,当将连接归还连接池前,必须进行参数重置 6 规则1.6 应用侧使用连接池场景,如使用连接创建过临时表,当将连接归还连接池前,必须手动清理所创建的临时表 7 对象设计规范 DATABASE对象设计 规则2.1 避免直接使用内置的DATABASE(如postgres、gaussdb等) 8 规则2.2 创建DATABASE时必须选择正确的数据库编码 9 规则2.3 创建DATABASE时必须选择正确的数据库兼容模式 10 建议2.4 存在关联计算的对象放在同一个DATABASE中 11 USER对象设计 规则2.5 禁止使用特殊权限用户运行业务,需遵循权限最小分配原则 12 规则2.6 禁止使用一个数据库用户运行所有业务 13 SCHEMA对象设计 建议2.7 不在其他USER的私有SCHEMA下创建对象 14 TABLESPACE对象设计 规则2.8 禁止自定义TABLESPACE表空间 15 TABLE对象设计(重点) 规则2.9 创建表时必须选择正确的分布方式和分布列 16 规则2.10 创建表时必须选择正确的存储方式 17 规则2.11 创建表时必须选择正确的分区策略 18 建议2.12 表字段的设计要遵循高效、准确原则 19 建议2.13 避免使用自增列或自增数据类型 20 INDEX对象设计(重点) 规则2.14 只创建必要的索引,创建索引必须选择合适的列和顺序 21 建议2.15 列存表通常可不建索引,极致性能场景需正确选择索引类型 22 VIEW对象设计 建议2.16 视图的嵌套需避免超过三层 23 SQL开发规范 DDL操作规范 建议3.1 DDL操作(CREATE除外)避免在业务高峰期和长事务中执行 24 规则3.2 DROP删除对象操作必须明确删除对象范围 25 INSERT操作规范 规则3.3 INSERT多VALUES批插场景使用COPY替代 26 建议3.4 禁止针对普通列存表进行实时INSERT操作 27 UPDATE/DELETE操作规范 建议3.5 避免并发UPDATE/DELETE行存表的同一行 28 建议3.6 避免对列存表频繁或并发执行UPDATE/DELETE 29 SELECT操作规范 规则3.7 禁止执行不下推的SQL 30 规则3.8 禁止多表关联时缺少关联条件 31 规则3.9 多表关联字段数据类型要保持一致 32 建议3.10 尽量避免对关联条件字段和过滤条件字段进行函数运算 33 建议3.11 资源高消耗型SQL需做好压测和并发管控 34 规则3.12 禁止针对行存大表的频繁COUNT 35 建议3.13 避免查询返回超大结果集(数据导出场景除外) 36 建议3.14 查询时避免使用“SELECT *”写法 37 建议3.15 谨慎使用递归语句(WITH RECURSIVE),明确终止条件,确保递归可终止 38 建议3.16 访问对象(表,函数等)时带上SCHEMA名称 39 建议3.17 针对SQL标记注释,唯一标识SQL的归属 40 外表功能开发规范 GDS外表 规则4.1 GDS服务须单独使用服务器部署在DWS集群外 41 协同分析外表 规则4.2 避免同时对多个协同分析外表进行跨集群并发访问 42 存储过程开发规范 - 建议5.1 避免使用复杂的存储过程,避免存储过程嵌套 43 规则5.2 存储过程内避免执行非CREATE类的DDL操作
  • 规则1.5 应用侧使用连接池场景,如使用连接SET设置过参数,当将连接归还连接池前,必须进行参数重置 违反规则的影响: 连接被其他业务复用时,可能会应复用其他业务设置的参数出现业务性能、业务报错等问题。 方案建议: 在将连接归还连接池之前,使用“SET SESSION AUTHORIZATION DEFAULT;RESET ALL;”重置参数。 注意: 在应用侧使用连接池的场景,如果在DWS服务侧通过GS_GUC RELOAD设置了全局的GUC参数,需要重启应用侧连接池该参数才可以生效,因为该设置只针对新建的连接生效,针对连接池中原有的连接不生效。
  • 规则1.3 开启的事务最后必须提交或回滚 违反规则的影响: 事务长时间不提交,持锁阻塞ALTER等操作,进而阻塞所有业务。 大量“idle in transaction”连接,触发连接上限,导致新建连接报错。 方案建议: 默认使用autocommit自动提交方式,如关闭autocommit,则必须手动提交。 显式start transaction开启的事务,执行完相关操作后,必须显式commit/rollback结束事务。
  • 建议4.1 避免使用复杂的存储过程,避免存储过程嵌套 违反规范的影响: 复杂和嵌套的存储过程维护成本高,故障定位难度大,恢复耗时长。 方案建议: 不使用存储过程或只使用一层存储过程,不嵌套。 开发存储过程设计对应的日志表,将关键步骤前后的信息记录到日志表中,操作步骤如下。 保存并查看日志操作步骤 创建日志表。 1 2 3 4 5 6 7 8 9 CREATE TABLE func_exec_log ( id varchar2(32) default lower(sys_guid()), pro_name varchar2(60), exec_times int, log_date date, deal_date date, log_mesage text ); 创建表和导入数据。 1 2 CREATE TABLE demo_table(data_id int, data_number int); INSERT INTO demo_table values(generate_series(1,1000),generate_series(1,1000)); 创建业务存储过程 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 CREATE OR REPLACE FUNCTION demo_table_process(out exe_info text) LANGUAGE plpgsql AS $$ declare v_count int; pro_result text; fun_name text; exec_times int; begin fun_name := 'demo_table_process'; select nvl(max(exec_times), '0') + 1 into exec_times from func_exec_log where pro_name = fun_name; --业务表插入数据 insert into demo_table values (dbms_random.value(1, 1000)::int,generate_series(1, dbms_random.value(10000, 20000)::int)); get diagnostics v_count = ROW_COUNT; exe_info = sysdate || '# step1:insert count:' || v_count || ' rows;'; --删除业务表指定数据 delete from demo_table where data_id = dbms_random.value(1, 1000)::int; get diagnostics v_count = ROW_COUNT; exe_info = exe_info || sysdate || '# step2:delete count:' || v_count || ' rows;'; --更新业务表数据 update demo_table set data_number = dbms_random.value(1, 100)::int where data_id = dbms_random.value(1, 1000)::int; exe_info = exe_info || sysdate || '# step3:update count:' || sql%rowcount || ' rows'; --在整个程序结束前记录日志,也可以在每个步骤结束后分别记录日志,也可以创建记录日志的函数供调用,灵活使用即可 insert into func_exec_log(pro_name, exec_times, log_date, deal_date, log_mesage) values (fun_name,exec_times,sysdate,split_part(regexp_split_to_table(exe_info, ';'), '#', 1),split_part(regexp_split_to_table(exe_info, ';'), '#', 2)); --EXCEPTION用于保证当insert/update/delete等操作步骤异常退出时,也能够正常记录日志 EXCEPTION WHEN OTHERS THEN pro_result := exe_info || sysdate || '# exception error message is: ' || sqlerrm; insert into func_exec_log(pro_name, exec_times, log_date, deal_date, log_mesage) values(fun_name,exec_times,sysdate,split_part(regexp_split_to_table(pro_result, ';'), '#', 1),split_part(regexp_split_to_table(pro_result, ';'), '#', 2)); END; $$; 调用存储过程(正常执行)。 1 SELECT demo_table_process(); 查看日志(确认业务运行情况)。 SELECT * FROM func_exec_log ORDER BY log_date desc,deal_date,log_mesage; 再次调用存储过程(构造执行异常)。 SELECT demo_table_process(); --先删除demo_table的data_number列构造异常,之后再调用 查看日志(确认业务运行情况)。
  • 开发设计建议概述 开发设计建议约定数据库建模和数据库应用程序开发过程中,应当遵守的设计规范。依据这些规范进行建模,能够更好地契合GaussDB的分布式处理架构,输出更高效的业务SQL代码。 开发设计建议中所陈述的“建议”和“关注”含义如下: 建议:用户应当遵守的设计规则。遵守这些规则,能够保证业务的高效运行;违反这些规则,将导致业务性能的大幅下降或某些业务逻辑错误。 关注:在业务开发过程中用户需要注意的细则。用于标识容易导致用户理解错误的知识点(实际上遵守SQL标准的SQL行为),或者程序中潜在的用户不易感知的默认行为。 父主题: 开发设计建议
  • DDL 在GaussDB中,建议DDL(建表、COMMENT等)操作统一执行。在批处理作业中尽量避免DDL操作,避免大量并发事务对性能的影响。 在非日志表(unlogged table)使用完后,立即执行数据清理(TRUNCATE)操作。因为在异常场景下,GaussDB不保证非日志表(unlogged table)数据的安全性。 临时表和非日志表的存储方式建议和基表相同。 索引字段的总长度不超过50字节。否则,索引大小会膨胀比较严重,带来较大的存储开销,同时索引性能也会下降。 不要使用DROP…CASCADE方式删除对象,除非已经明确对象间的依赖关系,以免误删。 详细DDL语法请参见DDL语法一览表。
  • 数据加载和卸载 在INSERT语句中显式设置插入的字段列表。例如: 1 INSERT INTO task(name,id,comment) VALUES ('task1','100','第100个任务'); 在批量数据入库之后,或者数据增量达到一定阈值后,建议对表进行ANALYZE操作,防止统计信息不准确而导致的执行计划劣化。 如果要清理表中的所有数据,建议使用TRUNCATE TABLE方式,不要使用DELETE TABLE方式。DELETE TABLE方式删除性能差,且不会释放那些已经删除了的数据占用的磁盘空间。
  • 开发设计建议概述 开发设计建议约定数据库建模和数据库应用程序开发过程中,应当遵守的设计规则。根据这些规则进行建模,能够更好地契合GaussDB的处理架构,输出更高效的业务SQL代码。 开发设计建议中所陈述的“建议”和“关注”含义如下: 建议:用户应当遵守的设计规则。遵守这些规则,能够保证业务的高效运行。违反这些规则,将导致业务性能的大幅下降或某些业务逻辑错误。 关注:在业务开发过程中用户需要注意的细则。用于标识容易导致用户理解错误的知识点(实际上遵守SQL标准的SQL行为),或者程序中潜在的用户不易感知的默认行为。 父主题: 开发设计建议
  • 数据库对象命名 数据库对象命名需要满足约束: 标识符表长度不超过63个字节。若需要对建有全局二级索引(GSI)的表执行COPY、GDS数据导入操作,则表名长度不超过38个字节。 标识符以字母或下划线开头,中间字符可以是字母、数字、下划线、$、#。 若标识符被双引号("")包含或者MYSQL模式下被反引号(``)包含,则可以使用合法字符的任意组合,如"123gs_column"。 标识符不区分大小写,只有被双引号包含或者MYSQL模式下被反引号(``)包含才区分大小写。 不支持gsql快捷命令(除\sf)查询反引号包含的对象名。 避免使用保留或者非保留关键字命名数据库对象。 可以使用select * from pg_get_keywords()查询GaussDB的关键字,或者在关键字章节中查看。 避免使用双引号括起来的字符串来定义数据库对象名称,除非需要限制数据库对象名称的大小写。数据库对象名称大小写敏感会使定位问题难度增加。 数据库对象命名风格务必保持统一。 增量开发的业务系统或进行业务迁移的系统,建议遵守历史的命名风格。 建议使用多个单词组成,以下划线分割。 数据库对象名称建议能够望文知意,尽量避免使用自定义缩写(可以使用通用的术语缩写进行命名)。例如,在命名中可以使用具有实际业务含义的英文词汇或汉语拼音,但规则应该在集群范围内保持一致。 变量名的关键是要具有描述性,即变量名要有一定的意义,变量名要有前缀标明该变量的类型。 表对象的命名应该可以表征该表的重要特征。例如,在表对象命名时区分该表是普通表、临时表还是非日志表: 普通表名按照数据集的业务含义命名。 临时表以“tmp_+后缀”命名。 非日志表以“ul_+后缀”命名。 外表以“f_+后缀”命名。 不创建以redis_为前缀的数据库对象。 不创建以pgxc_redistb为命名的数据库对象。 不创建以mlog_和以matviewmap_为前缀的数据库对象。 不创建以gs_role_为前缀的数据库对象。 表对象命名建议不要超过63字节。如果超过该长度内核会对表名进行截断,从而造成实际名称和设置值不一致的现象,且在不同字符集下,可能造成字符被截断,出现预期外的字符。 若需要对建有全局二级索引(GSI)的表执行COPY、GDS数据导入操作,则表名长度不超过38个字节。如果超过该长度,COPY、GDS导入过程中创建的临时表,可能触发表名截断,进而引发数据导入流程中断,出现预期外的字符等问题。 父主题: 开发设计建议
  • 数据库对象命名 数据库对象命名需要满足约束: 标识符表长度不超过63个字节。 标识符以字母或下划线开头,中间字符可以是字母、数字、下划线、$、#。 若标识符被双引号("")包含或者B模式下被反引号(``)包含,则可以使用合法字符的任意组合,如"123gs_column"。 标识符不区分大小写,只有被双引号包含或者B模式下被反引号(``)包含才区分大小写。 不支持gsql快捷命令(除了\sf)查询反引号包含的对象名。 避免使用保留或者非保留关键字命名数据库对象。 可以使用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方式删除对象,除非已经明确对象间的依赖关系,以免误删。 详细DDL语法请参见DDL语法一览表。
  • 数据加载和卸载 在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行为),或者程序中潜在的客户不易感知的默认行为。 父主题: 开发设计建议
  • 数据加载和卸载 【建议】在INSERT语句中显式给出插入的字段列表。例如: 1 INSERT INTO task(name,id,comment) VALUES ('task1','100','第100个任务'); 【建议】在批量数据入库之后,或者数据增量达到一定阈值后,建议对表进行ANALYZE操作,防止统计信息不准确而导致的执行计划劣化。 【建议】如果要清理表中的所有数据,建议使用TRUNCATE TABLE方式,不要使用DELETE TABLE方式。DELETE TABLE方式删除性能差,且不会释放那些已经删除了的数据占用的磁盘空间。