分析為什么只使用first_value的寫法,且為了完全使用first_value不惜二次sort,原因如下:
WINDOW CALL: WINDOW window_name (partition by xxx order by xxx)
在使用first_value,last_value的時候,partition和order by會對得出的結果有影響。
分析函數包含三個分析子句:partition by,order by ,window.window里面rows的方式如下:unbounded preceding(第一行),current row(當前行),unbounded following(最后一行)
(1)語句為(partition by xxx order by xxx),則默認的窗口為 unbounded preceding and current row
(2)語句為(partition by xxx), 窗口默認為unbounded preceding and unbounded following
(3)語句為(),窗口默認為全體結果集。
可能出現的問題就是語句使用第一種方式的時候。
測試環境如下:
create table windowcheck
(
?oc_date? integer ,
city???? varchar(50),
id?????? integer,
sale???? integer
);
select *from windowcheck;
?oc_date? | city |? id? | sale ?
----------+------+------+-------
20120701 | bj?? | 3299 | 10040
20120701 | cs?? | 3210 |? 7100
20120701 | nj?? | 3300 |? 8900
20120701 | nj?? | 3301 |? 9000
20120701 | tj?? | 3303 |? 3890
20120701 | wh?? | 3302 |? 4700
select oc_date,city,id,sale,last_value(sale) over (partition by oc_date order by city) last_value
from windowcheck;
?oc_date? | city |? id? | sale? | last_value
----------+------+------+-------+------------
20120701 | bj?? | 3299 | 10040 |????? 10040
20120701 | cs?? | 3210 |? 7100 |?????? 7100
20120701 | nj?? | 3301 |? 9000 |?????? 8900
20120701 | nj?? | 3300 |? 8900 |?????? 8900
20120701 | tj?? | 3303 |? 3890 |?????? 3890
20120701 | wh?? | 3302 |? 4700 |?????? 4700
問題出來了:我們通過oc_date進行分區,對city進行排序,得出的結果集最后一個值為wh,其sale值為4700.那我們原來的想法就是結果集所有的last_value應該都為4700。那么問題出在哪個地方呢?問題出在之前寫的窗口的范圍上了。有partition與order的默認的窗口為 unbounded preceding and current row。此時,讀取第一條的時候,窗口范圍僅自己一條,其last_value值為10040,讀取第二條的時候,窗口范圍為第一條與自己這一條,那么得出last_value值 為7100,以此類推.解決方案就是把窗口范圍擴大些。語句如下:
select oc_date,city,id,sale,last_value(sale) over (partition by oc_date order by city rows between unbounded preceding and unbounded following) last_value
from windowcheck;
到這里,把窗口范圍大小會引起的歧義解決了。還有一個疑惑是:如果在使用分區函數的時候,這個SQL語句本身也進行排序會怎么樣?因為SQL語句的結果集的順序會影響ast_value或者first_value的值。這里就要分析整個語句的先后執行順序了:分析函數是在整個SQL查詢結束后(SQL語句中的ORDER BY的執行比較特殊)再進行的操作, 也就是說
SQL語句中的ORDER BY也會影響分析函數的執行結果。分析語句如下:
--產生結果集的SQL語句的order by與分區函數里面的order by是一致的
select oc_date,city,id,sale,last_value(sale) over (partition by oc_date order by city rows between unbounded preceding and unbounded following) last_value
from windowcheck order by city;
?oc_date? | city |? id? | sale? | last_value
----------+------+------+-------+------------
20120701 | bj?? | 3299 | 10040 |?????? 4700
20120701 | cs?? | 3210 |? 7100 |?????? 4700
20120701 | nj?? | 3301 |? 9000 |?????? 4700
20120701 | nj?? | 3300 |? 8900 |?????? 4700
20120701 | tj?? | 3303 |? 3890 |?????? 4700
20120701 | wh?? | 3302 |? 4700 |?????? 4700
--產生結果集的SQL語句的order by與分區函數里面的order by不一致
select oc_date,city,id,sale,last_value(sale) over (partition by oc_date order by city rows between unbounded preceding and unbounded following) last_value
from windowcheck order by city desc;
?oc_date? | city |? id? | sale? | last_value
----------+------+------+-------+------------
20120701 | wh?? | 3302 |? 4700 |?????? 4700
20120701 | tj?? | 3303 |? 3890 |?????? 4700
20120701 | nj?? | 3301 |? 9000 |?????? 4700
20120701 | nj?? | 3300 |? 8900 |?????? 4700
20120701 | cs?? | 3210 |? 7100 |?????? 4700
20120701 | bj?? | 3299 | 10040 |?????? 4700
由以上二個語句,可以分析出:產生結果集的SQL語句里面的order by不會對分區函數里面的結果造成影響,原因是如果結果集的order by與分區函數里面的不一致時,先使用分區函數里面的order by進行結果運算,然后再執行結果集里面的order by.如果一致,則分區函數分析時不需要排序。
GP里面使用WINDOW的另外方式
select oc_date,city,id,sale,last_value(sale) over (w) last_value
from windowcheck
where oc_date=20120701
WINDOW w as? (partition by oc_date order by city rows between unbounded preceding and unbounded following);
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
