云服务器内容精选

  • 优化后 where条件中l_shipdate和l_quantity的distinct值数量较少且可以做min max过滤,将字段l_shipdate、l_quantity设置为PCK修改表定义如下: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 CREATE TABLE lineitem ( L_ORDERKEY BIGINT NOT NULL , L_PARTKEY BIGINT NOT NULL , L_SUPPKEY BIGINT NOT NULL , L_LINENUMBER BIGINT NOT NULL , L_QUANTITY DECIMAL(15,2) NOT NULL , L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL , L_DISCOUNT DECIMAL(15,2) NOT NULL , L_TAX DECIMAL(15,2) NOT NULL , L_RETURNFLAG CHAR(1) NOT NULL , L_LINESTATUS CHAR(1) NOT NULL , L_SHIPDATE DATE NOT NULL , L_COMMITDATE DATE NOT NULL , L_RECEIPTDATE DATE NOT NULL , L_SHIPINSTRUCT CHAR(25) NOT NULL , L_SHIPMODE CHAR(10) NOT NULL , L_COMMENT VARCHAR(44) NOT NULL , partial cluster key(l_shipdate, l_quantity) ) with (orientation = column) distribute by hash(L_ORDERKEY); 重新导入数据后执行查询,查看执行时间: 图3 使用partial cluster key 图4 使用partial cluster key后CU加载情况 使用partial cluster key后,5-- CS tore Scan on public.lineitem的时间减少了1.2s,得益于有84个CU被过滤掉了。
  • 优化建议 选取partial cluster key列。 列存表支持创建partial cluster key的类型character varying(n), varchar(n), character(n), char(n), text, nvarchar2, timestamp with time zone, timestamp without time zone, date, time without time zone, time with time zone。 数据的distinct值数量较少,这样能产生较好的过滤效果。 出现在查询where条件中,优先选取能过滤大量数据的列。 partial cluster key中设置多个列时,是先按第一个列排序,当第一个列值相同时,使用第二列比较,后续列依次类推。推荐不要超出3个列。
  • 现象描述 某局点测试中:ddw_f10_op_cust_asset_mon为分区表,分区键为year_mth,此字段是由年月两个值拼接而成的字符串。 测试SQL如下: 1 2 3 4 select count(1) from t_ddw_f10_op_cust_asset_mon b1 where b1.year_mth between to_char(add_months(to_date(''20170222'','yyyymmdd'), -11),'yyyymm') and substr(''20170222'',1 ,6 ); 测试结果显示此SQL的表Scan耗时长达135s。初步猜测可能是性能瓶颈点。 add_months为本地适配函数: 1 2 3 4 5 6 7 8 9 10 11 12 CREATE OR REPLACE FUNCTION ADD_MONTHS(date, integer) RETURNS date AS $$ SELECT CASE WHEN (EXTRACT(day FROM $1) = EXTRACT(day FROM (date_trunc('month', $1) + INTERVAL '1 month - 1 day'))) THEN date_trunc('month', $1) + CAST($2 + 1 || ' month - 1 day' as interval) ELSE $1 + CAST($2 || ' month' as interval) END $$ LANGUAGE SQL IMMUTABLE;
  • 现象描述 in-clause/any-clause是常见的SQL语句约束条件,有时in或any后面的clause都是常量,类似于: 1 2 3 4 select count(1) from calc_empfyc_c1_result_tmp_t1 where ls_pid_cusr1 in (‘20120405’, ‘20130405’); 或者: 1 2 3 4 select count(1) from calc_empfyc_c1_result_tmp_t1 where ls_pid_cusr1 in any(‘20120405’, ‘20130405’); 但是也有一些如下的特殊用法: 1 2 3 4 5 SELECT ls_pid_cusr1,COALESCE(max(round((current_date-bthdate)/365)),0) FROM calc_empfyc_c1_result_tmp_t1 t1,p10_md_tmp_t2 t2 WHERE t1.ls_pid_cusr1 = any(values(id),(id15)) GROUP BY ls_pid_cusr1; 其中:id,id15为p10_md_tmp_t2中的两列,“t1.ls_pid_cusr1 = any(values(id),(id15))”等价于“t1.ls_pid_cusr1 = id or t1.ls_pid_cusr1 = id15”。 因此join-condition实质上是一个不等式,这种非等值的join操作必须使用nestloop连接,对应执行计划如下:
  • 优化说明 测试发现由于两表结果集过大,导致nestloop耗时过长,超过一小时未返回结果,因此性能优化的关键是消除nestloop,让join使用更高效的hashjoin来连接。从语义等价的角度消除any-clause,SQL改写如下: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 select ls_pid_cusr1,COALESCE(max(round(ym/365)),0) from ( ( SELECT ls_pid_cusr1,(current_date-bthdate) as ym FROM calc_empfyc_c1_result_tmp_t1 t1,p10_md_tmp_t2 t2 WHERE t1.ls_pid_cusr1 = t2.id and t1.ls_pid_cusr1 != t2.id15 ) union all ( SELECT ls_pid_cusr1,(current_date-bthdate) as ym FROM calc_empfyc_c1_result_tmp_t1 t1,p10_md_tmp_t2 t2 WHERE t1.ls_pid_cusr1 = id15 ) ) GROUP BY ls_pid_cusr1; 优化后的SQL查询由两个等值join的子查询构成,而每个子查询都可以使用更适合此场景的hashjoin。优化后的执行计划如下: 优化后,从超过1个小时未返回结果优化到7s返回结果。
  • 优化说明 此优化的核心就是消除子查询。那么从SQL语义出发,可以等价改写SQL为: 1 2 3 4 5 6 select 1, coalesce(a4.c1, 0) from (select count(*) c1, a4.ca_address_sk from customer_address_001 a4 group by a4.ca_address_sk) a4 right join customer_address_001 a on a4.ca_address_sk = a.ca_address_sk;
  • 现象描述 1 2 3 4 select 1, (select count(*) from customer_address_001 a4 where a4.ca_address_sk = a.ca_address_sk) as GZCS from customer_address_001 a; 此SQL性能较差,查看发现执行计划中存在SubPlan,引用SubPlan结果的算子可能需要反复的调用获取这个SubPlan的值,即SubPlan以下的结果要重复执行很多次。具体如下:
  • 现象描述 某局点测试过程中EXPLAIN ANALYZE后有如下情况: 从执行信息上比较明确的可以看出HashJoin是整个计划的性能瓶颈点,并且从HashJoin的执行时间信息[2657.406,93339.924](数值的具体含义请参见SQL执行计划详解),上可以看出HashJoin在不同的DN上存在严重的计算倾斜。 同时在Memory Information(如下图)中可以看出各个节点的内存资源消耗也存在极为严重的倾斜。
  • 优化分析 上述两个特征表明了此SQL语句存在极为严重的计算倾斜。进一步向HashJoin算子的下层分析发现Seq Scan on s_riskrate_setting也存在极为严重的计算倾斜[38.885,2940.983]。根据Scan的含义推测此计划性能问题的根源在于表s_riskrate_setting数据的分布倾斜。实际分析之后确实发现表s_riskrate_setting存在严重的数据倾斜。整改之后性能从94s提升为50s。
  • 案例环境准备 为了便于规则的使用场景演示,需准备建表语句如下: --清理环境 DROP SCHEMA IF EXISTS rewrite_rule_guc_test CASCADE; CREATE SCHEMA rewrite_rule_guc_test; SET current_schema=rewrite_rule_guc_test; --创建测试表 CREATE TABLE t(c1 INT, c2 INT, c3 INT, c4 INT); CREATE TABLE t1(c1 INT, c2 INT, c3 INT, c4 INT); CREATE TABLE t2(c1 INT, c2 INT, c3 INT, c4 INT);
  • 案例环境准备 为了便于规则的使用场景演示,需准备建表语句如下: --清理环境 DROP SCHEMA IF EXISTS rewrite_rule_guc_test CASCADE; CREATE SCHEMA rewrite_rule_guc_test; SET current_schema=rewrite_rule_guc_test; --创建测试表 CREATE TABLE t(c1 INT, c2 INT, c3 INT, c4 INT); CREATE TABLE t1(c1 INT, c2 INT, c3 INT, c4 INT); CREATE TABLE t2(c1 INT, c2 INT, c3 INT, c4 INT);
  • 现象描述 某局点测试过程中EXPLAIN ANALYZE后有如下情况: 从执行信息上比较明确的可以看出HashJoin是整个计划的性能瓶颈点,并且从HashJoin的执行时间信息[2657.406,93339.924](数值的具体含义请参见SQL执行计划详解),上可以看出HashJoin在不同的DN上存在严重的计算偏斜。 同时在Memory Information(如下图)中可以看出各个节点的内存资源消耗也存在极为严重的偏斜。
  • 优化分析 上述两个特征表明了此SQL语句存在极为严重的计算倾斜。进一步向HashJoin算子的下层分析发现Seq Scan on s_riskrate_setting也存在极为严重的计算倾斜[38.885,2940.983]。根据Scan的含义推测此计划性能问题的根源在于表s_riskrate_setting数据的分布倾斜。实际分析之后确实发现表s_riskrate_setting存在严重的数据倾斜。整改之后性能从94s提升为50s。
  • 案例环境准备 为了便于案例演示,需准备建表语句如下: --清理环境 DROP SCHEMA IF EXISTS dn_gather_test CASCADE; CREATE SCHEMA dn_gather_test; SET current_schema=dn_gather_test; --创建测试表 CREATE TABLE t1(a INT, b INT, c INT, d INT); CREATE TABLE t2(a INT, b INT, c INT, d INT); CREATE TABLE t3(a INT, b INT, c INT, d INT); CREATE TABLE t4(a INT, b INT, c INT, d INT);
  • 案例环境准备 为了便于规则的使用场景演示,需准备建表语句如下: --清理环境 DROP SCHEMA IF EXISTS rewrite_rule_guc_test CASCADE; CREATE SCHEMA rewrite_rule_guc_test; SET current_schema=rewrite_rule_guc_test; --创建测试表 CREATE TABLE t(c1 INT, c2 INT, c3 INT, c4 INT); CREATE TABLE t1(c1 INT, c2 INT, c3 INT, c4 INT); CREATE TABLE t2(c1 INT, c2 INT, c3 INT, c4 INT);