云服务器内容精选

  • 建议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行为),或者程序中潜在的用户不易感知的默认行为。 父主题: 开发设计建议
  • 数据加载和卸载 在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方式删除对象,除非已经明确对象间的依赖关系,以免误删。 详细DDL语法请参见DDL语法一览表。
  • 开发设计建议概述 开发设计建议约定数据库建模和数据库应用程序开发过程中,应当遵守的设计规则。根据这些规则进行建模,能够更好地契合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字节。如果超过该长度内核会对表名进行截断,从而造成和设置值不一致的现象,且在不同字符集下,可能造成字符被截断,出现预期外的字符。 父主题: 开发设计建议
  • 数据加载和卸载 在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方式删除对象,除非已经明确对象间的依赖关系,以免误删。 详细DDL语法请参见DDL语法一览表。
  • 开发设计建议概述 本开发设计建议约定数据库建模和数据库应用程序开发过程中,应当遵守的设计规范。依据这些规范进行建模,能够更好地契合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方式删除性能差,且不会释放那些已经删除了的数据占用的磁盘空间。
  • DDL 【建议】在GaussDB中,建议DDL(建表、COMMENT等)操作统一执行。在批处理作业中尽量避免DDL操作。避免大量并发事务对性能的影响。 【建议】在非日志表(unlogged table)使用完后,立即执行数据清理(TRUNCATE)操作。因为在异常场景下,GaussDB不保证非日志表(unlogged table)数据的安全性。 【建议】临时表和非日志表的存储方式建议和基表相同。当基表为行存表时,临时表和非日志表也推荐创建为行存表,可以避免混合关联带来的高计算代价。 【建议】索引字段的总长度不超过50字节。否则,索引大小会膨胀比较严重,带来较大的存储开销,同时索引性能也会下降。 【建议】不要使用DROP…CASCADE方式删除对象,除非已经明确对象间的依赖关系,以免误删。
  • 开发设计建议概述 开发设计建议约定数据库建模和数据库应用程序开发过程中,应当遵守的设计规范。依据这些规范进行建模,能够更好地契合GaussDB的处理架构,输出更高效的业务SQL代码。 开发设计建议中所陈述的“建议”和“关注”含义如下: 建议:用户应当遵守的设计规则。遵守这些规则,能够保证业务的高效运行;违反这些规则,将导致业务性能的大幅下降或某些业务逻辑错误。 关注:在业务开发过程中用户需要注意的细则。用于标识容易导致用户理解错误的知识点(实际上遵守SQL标准的SQL行为),或者程序中潜在的用户不易感知的默认行为。 父主题: 开发设计建议
  • 开发设计建议概述 开发设计建议约定数据库建模和数据库应用程序开发过程中,应当遵守的设计规范。依据这些规范进行建模,能够更好地契合GaussDB的分布式处理架构,输出更高效的业务SQL代码。 开发设计建议中所陈述的“建议”和“关注”含义如下: 建议:用户应当遵守的设计规则。遵守这些规则,能够保证业务的高效运行;违反这些规则,将导致业务性能的大幅下降或某些业务逻辑错误。 关注:在业务开发过程中用户需要注意的细则。用于标识容易导致用户理解错误的知识点(实际上遵守SQL标准的SQL行为),或者程序中潜在的用户不易感知的默认行为。 父主题: 开发设计建议