表分割槽的陰暗面

本篇文章是我在:看到了，如我們所知，大家在介紹表分割槽的時候一直在歌頌其好處。但一句古諺語說的好，每個人都有其陰暗面，表分割槽也會在特定情況下反而降低其效能。

首先建立測試表,並在其上建立聚集索引:

create

table dbo.orders
(id int
notnull ,
orderdate datetime
notnull ,
datemodified datetime
notnull ,
placeholder char(500)
notnull
constraint def_data_placeholder default 'placeholder',
);gocreate
unique
clustered
index idx_orders_id
on dbo.orders(id);
go

然後插入測試資料:

with    n1 ( c )

as ( select 0
union
allselect 0
)-- 2 rows
, n2 ( c )
as ( select 0
from n1 as t1
cross
join n1 as t2
)-- 4 rows
, n3 ( c )
as ( select 0
from n2 as t1
cross
join n2 as t2
)-- 16 rows
, n4 ( c )
as ( select 0
from n3 as t1
cross
join n3 as t2
)-- 256 rows
, n5 ( c )
as ( select 0
from n4 as t1
cross
join n4 as t2
)-- 65,536 rows
, n6 ( c )
as ( select 0
from n5 as t1
cross
join n2 as t2
cross
join n1 as t3
)-- 524,288 rows
, ids ( id )
as ( select row_number() over ( order
by ( select
null
) )from n6
)select * from ids
insert
into dbo.orders
( id ,
orderdate ,
datemodified
)select id ,
dateadd(second, 35 * id, @startdate) ,
case
when id % 10 = 0
then dateadd(second,
24 * 60 * 60 * ( id % 31 ) + 11200 + id
% 59 + 35 * id, @startdate)
else dateadd(second, 35 * id, @startdate)
endfrom ids;
go

插入測試資料的**貌似複雜，其實只是通過遞迴cte的辦法生成自1開始的數字，然後為每乙個行插入略微遞增的日期。對於modifydate列，每10個記錄插入乙個略微大的值。此時執行如下查詢:

圖1.沒有分割槽的查詢計畫，看起來不錯

對應的，得到的統計資訊:

表 'orders'。掃瞄計數 1，邏輯讀取 310 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。

我們drop掉上面的索引後，重新進行表分割槽,如**3所示:

--drop索引

drop
index idx_orders_datemodified_id on dbo.orders;
drop
index idx_orders_id on dbo.orders;
go--分割槽函式
create partition function pforders(datetime)
as range right
forvalues 
('2012-02-01', '2012-03-01',
'2012-04-01','2012-05-01','2012-06-01',
'2012-07-01','2012-08-01');
go--分割槽方案
create partition scheme psorders 
as partition pforders
allto ([primary]);
go--再次建立聚集索引
create
unique
clustered
index idx_orders_orderdate_id
on dbo.orders(orderdate,id)
on psorders(orderdate);
go--再次建立非聚集索引
create
unique
index idx_data_datemodified_id_orderdate
on dbo.orders(datemodified, id, orderdate)
on psorders(orderdate);
go

然後，我們通過**2中的**，再次插入測試資料。然後再次執行圖1中所示查詢，得到的結果如圖2所示。

圖2.對錶分割槽後，效能直線下降

由執行計畫可以看出，查詢完全忽視了非聚集索引的存在，進行了表掃瞄。因此產生了巨大的消耗。

對應的統計資訊，如下:

(100 行受影響)

表'worktable'。掃瞄計數0，邏輯讀取0 次，物理讀取0 次，預讀0 次，lob 邏輯讀取0 次，lob 物理讀取0 次，lob 預讀0 次。
表'orders'。掃瞄計數2，邏輯讀取10071 次，物理讀取0 次，預讀2 次，lob 邏輯讀取0 次，lob 物理讀取0 次，lob 預讀0 次。
cpu 時間= 219 毫秒，占用時間= 783 毫秒。

因此，不要在生產環境中資料量一大就想到表分割槽。在進行表分割槽之前，首先考慮一下對分割槽計畫進行測試，否則在生產環境中出現上面的情況就悲劇了。

表分割槽的陰暗面（執行計畫）

careson 發表了一片博文其實我碰到過類似的事情，但是沒有仔細研究為什麼。藉著careson的demo，仔細的觀察了執行計畫。測試資料 當然第一步根據careson的demo建立乙份測試資料。第二步為了做比較的需要，建乙個非分割槽的非聚集索引，key 和 分割槽對齊的非聚集索引一樣。第三步建議乙...

如何看待社會的陰暗面

我發現乙個現象，這兩年微博的環境變的不一樣了。前兩三年微博上各種的公知大v，針砭時弊，高談闊論，但僅僅也就兩三年的時間，就變成了網紅娛樂圈的陣地，當然不變的是依然很熱鬧。各種的撕逼互殺依然在上演。當然這其中也存在著不少投機取巧的選手，後來就出現這樣的新聞，某造謠團夥被抓，很多知名大v開始浮出水面，但...

大學中的3大陰暗面, 一般人根本想象不到

在很多人的想象中，大學是乙個非常完美的地方。的確，對於大多數學生來說，大學是乙個充滿了美好回憶場景。不過，有陽光就會有陰影，再好的大學裡，也會有一些骯髒的事情發生。下面我們就來說說大學中那些少見，但的確存在的黑暗面。1 保研路 保研路對於很多人來說已經不是什麼隱秘了。或許很多人都聽學長學姐說過這樣的...