求条SQL语句,小弟我做的都想吐了,达人。
求条SQL语句,我做的都想吐了,在线等达人。。
数据如下表A:
--手机号 拨打时间
131 2012-01-01
131 2012-01-02
132 2012-01-05
133 2012-01-05
134 2012-01-06
133 2012-01-06
135 2012-01-20
需要得到如下结果:表B
--日期 打电话人数 近7天拨打人数
2012-01-01 1 1
2012-01-02 1 1
2012-01-05 2 3
2012-01-06 2 4
2012-01-20 1 1
关键是哪给近7天人数,A表数据量1E左右,请各位朋友给条性能不错的语句。谢谢了。
------最佳解决方案--------------------
习惯性分段处理,这样逻辑也比较清晰,不知道是否满足条件。
如果脚本慢的话,应该是第一个临时表,不过拨打时间应该有索引。
drop table 20121116_test_1;
create table 20121116_test_1 as
select 拨打时间,
count(1) 打电话人数
from a
group by 拨打时间;
drop table 20121116_test_2;
create table 20121116_test_2 as
select a.拨打时间,
a.打电话人数,
(select sum(打电话人数)
from 20121116_test_1
where 拨打时间>=a.拨打时间-6
and 拨打时间<=a.拨打时间) 近7天拨打人数
from 20121116_test_1 a;
------其他解决方案--------------------
1 优化是技术不是魔法,不是哈利波特拿个小棍一指“快”它就快了。如果你的数据库做了很多无用功(比如可以一行做4个计算解决问题,却遍历了4次,每行只计算一个结果),可以优化。
但是如果数据库选择的是相对合理的方式,做的操作都是必须的步骤,那么慢你也只能忍。
2 具体到这里,一个简单的行转列就可以解决问题,如果还闲慢,那么看能不能建函数索引,如果因为最近7天是个变化值,索引也无效,那么就考虑建立物化视图,因为1亿多数据,真正拨打是35000次还是35001次真的很重要否?不是就牺牲一点点实时性换性能。
3 换我就给表加索引,建物化视图,每天凌晨没有数据进入时用定时任务作收集分析,再慢就让需求方忍着。
------其他解决方案--------------------
没看懂 你的那个7天的列 咋算的。
------其他解决方案--------------------
--日期 打电话人数 近7天拨打人数
2012-01-01 1 1 --指131的那个手机号
2012-01-02 1 1 --还是131的手机号
2012-01-05 2 3 --131,132,133这3个手机号
2012-01-06 2 4
2012-01-20 1 1
数据如下表A:
--手机号 拨打时间
131 2012-01-01
131 2012-01-02
132 2012-01-05
133 2012-01-05
134 2012-01-06
133 2012-01-06
135 2012-01-20
需要得到如下结果:表B
--日期 打电话人数 近7天拨打人数
2012-01-01 1 1
2012-01-02 1 1
2012-01-05 2 3
2012-01-06 2 4
2012-01-20 1 1
关键是哪给近7天人数,A表数据量1E左右,请各位朋友给条性能不错的语句。谢谢了。
------最佳解决方案--------------------
习惯性分段处理,这样逻辑也比较清晰,不知道是否满足条件。
如果脚本慢的话,应该是第一个临时表,不过拨打时间应该有索引。
drop table 20121116_test_1;
create table 20121116_test_1 as
select 拨打时间,
count(1) 打电话人数
from a
group by 拨打时间;
drop table 20121116_test_2;
create table 20121116_test_2 as
select a.拨打时间,
a.打电话人数,
(select sum(打电话人数)
from 20121116_test_1
where 拨打时间>=a.拨打时间-6
and 拨打时间<=a.拨打时间) 近7天拨打人数
from 20121116_test_1 a;
------其他解决方案--------------------
1 优化是技术不是魔法,不是哈利波特拿个小棍一指“快”它就快了。如果你的数据库做了很多无用功(比如可以一行做4个计算解决问题,却遍历了4次,每行只计算一个结果),可以优化。
但是如果数据库选择的是相对合理的方式,做的操作都是必须的步骤,那么慢你也只能忍。
2 具体到这里,一个简单的行转列就可以解决问题,如果还闲慢,那么看能不能建函数索引,如果因为最近7天是个变化值,索引也无效,那么就考虑建立物化视图,因为1亿多数据,真正拨打是35000次还是35001次真的很重要否?不是就牺牲一点点实时性换性能。
3 换我就给表加索引,建物化视图,每天凌晨没有数据进入时用定时任务作收集分析,再慢就让需求方忍着。
------其他解决方案--------------------
没看懂 你的那个7天的列 咋算的。
------其他解决方案--------------------
--日期 打电话人数 近7天拨打人数
2012-01-01 1 1 --指131的那个手机号
2012-01-02 1 1 --还是131的手机号
2012-01-05 2 3 --131,132,133这3个手机号
2012-01-06 2 4
2012-01-20 1 1