为啥用了临时表后5000秒降到3秒

代码如下: 把cs_thz_1的cs_thz_11用原sql替代,则cs_thz_1要跑5000秒,改造后,3秒,临时表的数据是16W,2019年一直运行时间在20秒内,2020年以后突然升到5000秒,要插入的目标表只有主键,没有分区,不知道什么原因???

改造后:

create table cs_thz_11 as
select * from R_DW_HelpER_RELATION_D
where stat_time= 20200119 and FAM_STATUS=1 and 20200119 between nvl(help_START_DATE,19000101) and nvl(help_END_DATE,29991231)
;

drop table cs_thz_1;
create table cs_thz_1 as
select
20200119 as stat_time --统计日期
,a.helper_id as helper_id --帮扶负责人id
,a.helper_name as helper_name --帮扶负责人名称
,nvl(x.poor_fam,0) as poor_fam --贫困户数
,nvl(x.poor_pop,0) as poor_pop --贫困人口数
,nvl(x.gov_exp_pop,0) as gov_exp_pop --行业比对存疑人数
,nvl(x.gov_exp_item,0) as gov_exp_item --行业比对存疑条数
,nvl(y.hg_exp_pop,0) as hg_exp_pop --手册比对存疑人数
,nvl(y.hg_exp_item,0) as hg_exp_item --手册比对存疑条数
,sysdate as flow_time --流入时间
from TW_HELP_PERSON_D a
left join (---行业存疑
select t.helper_id,count(distinct t.fam_id) as poor_fam
,sum(case when t.rid=1 then t.fam_pop else 0 end) as poor_pop
,count(distinct t.pop_id) as gov_exp_pop
,count(t.pop_id) as gov_exp_item
from (
select row_number() over (partition by a.helper_id,a.fam_id order by 1) rid,a.fam_id,a.helper_id,a.fam_pop,b.pop_id
from cs_thz_11 a
left join (select * from app_dw_identify_exception_d where stat_time=20200119 and IS_SUB_SOLVE = 0) b
on a.fam_id=b.fam_id
) t
group by t.helper_id
) x on a.helper_id=x.helper_id
left join (---手册比对存疑
select a.helper_id,count(distinct b.idcard18) as hg_exp_pop,count(b.idcard18) as hg_exp_item
from cs_thz_11 a
left join (select * from app_dw_compare_exception_d where stat_time=20200119 ) b
on a.fam_id=b.residence_id
group by a.helper_id
) y on a.helper_id=y.helper_id
where a.stat_time=20200119
;

原文地址:https://www.cnblogs.com/jiangqingfeng/p/12220777.html

时间: 2024-10-25 22:26:40

为啥用了临时表后5000秒降到3秒的相关文章

win8.1开机后 桌面会莫名的卡5秒

最近win8.1开机后 桌面会莫名的卡5秒 ,查看事件 事件 ID:10010描述:服务器{1B1F472E-3221-4826-97DB-2C2324D389AE} 没有在要求的超时时间内向 DCOM 注册. 更新: 禁用Skydrive两个计划任务,错误依旧 转自远景论坛 体的方式是通过给 Network Service 角色添加相应的权限,步骤如下:A. 在"运行"里面输入命令dcomcnfgB. 双击"组件服务"->双击"计算机"C

ASIHTTPRequest 记录过去5秒的平均流量字节/秒

//记录过去5秒的平均流量字节/秒 NSLog(@"%llu",[ASIHTTPRequest averageBandwidthUsedPerSecond]); ASIHTTPRequest 记录过去5秒的平均流量字节/秒

一秒快速抠图一秒图片高清处理

作为运营人,作为平面设计师.我们离不开与图片设计.图片处理等相关的工作.在运营工作新人中,很多新的运营专员/运营者对Ps并不是特别熟练.我们也知道除外PS还有其它非主流的抠图软件,但是大体都是描绘一个边然后软件进行抠图处理.但是很多时候这种软件抠出来的图并不标准,无论是图片边缘的细节还是整体的处理. 这篇文章给运营者带来两个运营工作中图片处理的小技巧.如何一秒快速抠图?如何一秒图片高清处理? 一秒快速抠图 在演示之前,我在百度图片中随机选择了几张图,下图是给大家演示如何快速的1秒抠图 . 一秒图

Kafka实战:如何把Kafka消息时延秒降10倍

背景 中软独家中标税务核心征管系统,全国34个省国/地税.电子税务局15省格局.大数据×××局点,中国软件电子税务局技术路径:核心征管 + 纳税服务 业务应用分布式上云改造. 业务难题 如上图所示是模拟客户的业务网页构建的一个并发访问模型.用户在页面点击从而产生一个HTTP请求,这个请求发送到业务生产进程,就会启动一个投递线程(Deliver Thread)调用Kafka的SDK接口,并发送3条消息到DMS(分布式消息服务),每条消息大小3k,需要等待3条消息都被处理完成后才会返回请求响应⑧.当

计算从现在到明年的倒计时(包含天,时,分,秒),每秒更新一次

function timeCount(){ var nowTime=Date.parse(new Date()); var toTime=Date.parse(new Date('2018 01 01')); var jiange=(toTime-nowTime)/1000; var day=Math.floor(jiange/3600/24); var hh=Math.floor((jiange%(3600*24))/(60*60)); var mm=Math.floor(((jiange%(

百度MP3+图片+文字:生成结果文件;(声音58秒,视频59秒,同步性需要进一步优化)

import os os_sep = os.sep this_file_abspath = os.path.abspath(__file__) this_file_dirname, this_file_name = os.path.dirname(this_file_abspath), os.path.abspath(__file__).split(os_sep)[ -1] f_mp3 = '{}{}{}'.format(this_file_dirname, os_sep, 'auido.mp3

一千万个随机数排序,如何24秒蜕变成3秒?如何从700M内存消耗变成200M?

上一篇文章写的十分的烂,经过科普看语言源码实现用的是quicksort实现的底层排序,在这里模仿一下,勿喷! package main import ( "fmt" "math/rand" "runtime" "sort" "time" ) func mergeonce(l, r []int) []int { m := make([]int, 0, len(l)+len(r)) i, j := 0, 0 i

实现两个unix时间戳的差,并返回两个时间戳相差的天、小时、分、秒,精确到秒

function timediff($begin_time,$end_time) { if($begin_time < $end_time){ $starttime = $begin_time; $endtime = $end_time; } else{ $starttime = $end_time; $endtime = $begin_time; } $timediff = $endtime-$starttime; $days = intval($timediff/86400); $remai

强制SQL Server执行计划使用并行提升在复杂查询语句下的性能

最近在给一个客户做调优的时候发现一个很有意思的现象,对于一个复杂查询(涉及12个表)建立必要的索引后,语句使用的IO急剧下降,但执行时间不降反升,由原来的8秒升到20秒. 通过观察执行计划,发现之前的执行计划在很多大表连接的部分使用了Hash Join,由于涉及的表中数据众多,因此查询优化器选择使用并行执行,速度较快.而我们优化完的执行计划由于索引的存在,且表内数据非常大,过滤条件的值在一个很宽的统计信息步长范围内,导致估计行数出现较大偏差(过滤条件实际为15000行,步长内估计的平均行数为80