|
|
和壓縮（Compression）相比，數(shù)據(jù)庫(kù)分區(qū)（Partition）的操作更為復(fù)雜繁瑣。而且與Compression一次操作，終身保持不同，分區(qū)是一項(xiàng)需要長(zhǎng)期維護(hù)周期變更的操作。
分區(qū)的意義在于將大數(shù)據(jù)從物理上切割為幾個(gè)相互獨(dú)立的小部分，從而在查詢(xún)時(shí)只取出其中一個(gè)或幾個(gè)分區(qū)，減少影響的數(shù)據(jù)；另外對(duì)于置于不同文件組的分區(qū)，并行查詢(xún)的性能也要高于對(duì)整個(gè)表的查詢(xún)性能。
事實(shí)上，在SQL Server 2005中就已經(jīng)包含了分區(qū)功能，甚至在2005之前，還存在一個(gè)叫做“Partitioned Views”的功能，能通過(guò)將同樣結(jié)構(gòu)的表Union在一個(gè)View中，實(shí)現(xiàn)類(lèi)似現(xiàn)在分區(qū)表的效果。而在SQL Server 2008中，分區(qū)功能得到了顯著加強(qiáng)，使得我們不僅能夠?qū)Ρ砗退饕龇謪^(qū)，而且允許對(duì)分區(qū)上鎖，而不是之前的全表上鎖。
指定分區(qū)列
和Compression一樣，在SQL Server 2008中也提供了分區(qū)的向?qū)Ы缑妗Ｔ谄髽I(yè)管理器中，需要分區(qū)的表上右鍵選擇Storage-》Create Partition:
這里會(huì)列出該表所有的字段，包括字段類(lèi)型、長(zhǎng)度、精度及小數(shù)位數(shù)的信息，可以選擇其中的任意一一列作為分區(qū)列（Patitioning Column），不僅僅是數(shù)字或者日期類(lèi)型，即使是字符串類(lèi)型的列，也可以按照字母順序進(jìn)行分區(qū)。而以下類(lèi)型的列不可用于分區(qū)：text、ntext、image、xml、timestamp、varchar(max)、nvarchar(max)、varbinary(max)、別名、hierarchyid、空間索引或 CLR 用戶(hù)定義的數(shù)據(jù)類(lèi)型。此外，如果使用計(jì)算列作為分區(qū)列，則必須將該列設(shè)為持久化列（Persisit）。
在列表下方，提供了兩個(gè)選項(xiàng)：
- 分配到可用分區(qū)表：
這要求在同一數(shù)據(jù)庫(kù)下有另一張已分好區(qū)的表，同時(shí)該表的分區(qū)列和當(dāng)前選中的列的類(lèi)型完全一致。
這樣的好處是當(dāng)兩張表在查詢(xún)中有關(guān)聯(lián)時(shí)，并且其關(guān)聯(lián)列就是分區(qū)列時(shí)，使用同樣的分區(qū)策略會(huì)更有效率。 - 將非唯一索引和唯一索引的存儲(chǔ)空間調(diào)整為與索引分區(qū)列一致：
這樣會(huì)將表中的所有索引也一同分區(qū)，實(shí)現(xiàn)“對(duì)齊”。這是一個(gè)重要而麻煩的選項(xiàng)，具體需求請(qǐng)參閱MSDN（已分區(qū)索引的特殊指導(dǎo)原則）。
這樣的好處是表和索引的分區(qū)一致，一方面查詢(xún)時(shí)利用索引更為高效，而且在下文提到的移入移出分區(qū)也會(huì)更為高效。
注意：這里建議使用聚集索引列作為分區(qū)列。一方面索引結(jié)構(gòu)本身就應(yīng)與查詢(xún)相關(guān)，那么分區(qū)列與索引一致會(huì)保證查詢(xún)的最大效率；另一方面，保證索引對(duì)齊而且是聚集索引對(duì)齊是保證分區(qū)的移入移出操作順暢的前提，否則可能會(huì)出現(xiàn)無(wú)法移入移出的情況，而分區(qū)的移入移出又是管理大數(shù)據(jù)的重要策略——滑動(dòng)窗口（SlideWindow）策略的基礎(chǔ)操作。
分區(qū)函數(shù)與分區(qū)方案
選好分區(qū)列后，如果沒(méi)有應(yīng)用“分配到可用分區(qū)表”選項(xiàng)，接下來(lái)則會(huì)進(jìn)入選擇/創(chuàng)建分區(qū)函數(shù)以及分區(qū)方案的界面。其中分區(qū)函數(shù)會(huì)指定分區(qū)邊界，而分區(qū)方案則規(guī)劃了每個(gè)分區(qū)所存儲(chǔ)的文件組。
向?qū)Р僮鹘缑嫒缦拢?/p>
其中Left boundary說(shuō)明每個(gè)分區(qū)的邊界值被包含在邊界值左側(cè)的分區(qū)中，也就是每個(gè)分區(qū)內(nèi)的數(shù)據(jù)約束是<=指定的邊界值，相應(yīng)的，Right boundary則說(shuō)明每個(gè)分區(qū)的邊界值被包含在邊界值右側(cè)的分區(qū)中，每個(gè)分區(qū)內(nèi)的數(shù)據(jù)約束是<指定的邊界值。
在下方的列表中，列出了當(dāng)前分區(qū)方案下現(xiàn)有的分區(qū)。其中文件組（Filegroup）指定了每個(gè)分區(qū)存放的位置，如果將分區(qū)放置于位于不同磁盤(pán)中的不同文件組中，由于不同磁盤(pán)的讀寫(xiě)互不干擾，這將提高分區(qū)表并行處理的效率。一般情況下，將所有分區(qū)放置在同一個(gè)文件組是比較穩(wěn)妥的做法。關(guān)于文件組的展開(kāi)閱讀可以參閱：SQL Server Filegroups。
注意，在這里最后一個(gè)分區(qū)是沒(méi)有指定邊界的，用于保存所有>(Left Boundary)或>=(Right boundary)最后一個(gè)分區(qū)邊界的數(shù)據(jù)。
如果選擇時(shí)間類(lèi)型的字段作為分區(qū)列，可以通過(guò)Set按鈕實(shí)現(xiàn)按條件分組：
這樣可以很方便得通過(guò)設(shè)置起止時(shí)間將表按照指定時(shí)間段自動(dòng)分區(qū)，但之后依然需要手動(dòng)指定每個(gè)分區(qū)的文件組。
制定好分區(qū)方案之后可以通過(guò)Estimate sotrage預(yù)估每個(gè)分區(qū)的行數(shù)、空間占用情況，不過(guò)除非需要以占用空間或行數(shù)來(lái)規(guī)劃你的分區(qū)策略，一般不建議在這里進(jìn)行預(yù)估，因?yàn)槿绻麑?duì)空表來(lái)說(shuō)，預(yù)估的結(jié)果當(dāng)然都是0，而如果表中已經(jīng)包含大量數(shù)據(jù)，預(yù)估則會(huì)花費(fèi)比較長(zhǎng)的時(shí)間。
創(chuàng)建分區(qū)
通過(guò)以上設(shè)置，分區(qū)已經(jīng)基本完畢，在向?qū)У淖詈螅梢赃x擇是創(chuàng)建腳本還是立即執(zhí)行分區(qū)操作。
我們可以查看在不同情況下創(chuàng)建分區(qū)的腳本的情況：
1.在表沒(méi)有索引的情況下：
BEGIN TRANSACTIONCREATE PARTITION FUNCTION [TestFunction](datetime) AS RANGE LEFT FOR VALUES (N'2010-01-01T00:00:00', N'2010-02-01T00:00:00',
N'2010-03-01T00:00:00', N'2010-04-01T00:00:00', N'2010-05-01T00:00:00', N'2010-06-01T00:00:00')CREATE PARTITION SCHEME [TestScheme] AS PARTITION [TestFunction] TO ([PRIMARY], [PRIMARY], [PRIMARY],
[PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY])CREATE CLUSTERED INDEX [ClusteredIndex_on_TestScheme_634025264502439124] ON [dbo].[Account] ( [birthday])WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [TestScheme]([birthday])DROP INDEX [ClusteredIndex_on_TestScheme_634025264502439124] ON [dbo].[Account] WITH ( ONLINE = OFF )COMMIT TRANSACTION
這里先創(chuàng)建Partition Function以及Partition Scheme，之后在分區(qū)列上創(chuàng)建聚集索引并按照分區(qū)方案分區(qū)，最后刪除了這一索引。
2.在表有索引的情況下：
如果原先沒(méi)有聚集索引：
CREATE CLUSTERED INDEX [ClusteredIndex_on_TestScheme_634025229911990663] ON [dbo].[Account] ( [birthday])WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [TestScheme]([birthday])DROP INDEX [ClusteredIndex_on_TestScheme_634025229911990663] ON [dbo].[Account] WITH ( ONLINE = OFF )
這和沒(méi)有索引的情況一樣，如果表原先存在聚集索引，則腳本變?yōu)椋?/p>
CREATE CLUSTERED INDEX [IX_id] ON [dbo].[Account] ( [id] ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = ON,
ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [TestScheme]([birthday])
可以看到原有的聚集索引（IX_id）在分區(qū)方案上被重建了。
如果選擇了“對(duì)齊索引”選項(xiàng)，則會(huì)對(duì)所有索引都應(yīng)用分區(qū)：
CREATE CLUSTERED INDEX [IX_id] ON [dbo].[Account] ( [id] ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = ON,
ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [TestScheme]([birthday])CREATE NONCLUSTERED INDEX [UIX_birthday] ON [dbo].[Account] ( [birthday] ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = ON,
ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [TestScheme]([birthday])CREATE NONCLUSTERED INDEX [UIX_name] ON [dbo].[Account] ( [name] ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = ON,
ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
這里不僅對(duì)聚集索引IX_id進(jìn)行了分區(qū)，也對(duì)非聚集索引UIX_name和UIX_birthday進(jìn)行了分區(qū)。
注意事項(xiàng)
- 對(duì)一張表分好區(qū)后不可以進(jìn)行再次分區(qū)，同時(shí)也沒(méi)有直接取消表分區(qū)的方法。
- 如果要查看已分區(qū)表的分區(qū)狀態(tài)以及每個(gè)分區(qū)中的行數(shù)和占用空間，可以通過(guò)Storage-》Management Compression查看。同時(shí)可以在這里為每個(gè)分區(qū)指定壓縮方式。
- 如果分區(qū)表索引沒(méi)有對(duì)齊，則不可以對(duì)該表進(jìn)行切入切出（Switch in/out）操作，同樣也不能執(zhí)行滑動(dòng)窗口操作。
- 分區(qū)實(shí)際上是在每個(gè)分區(qū)表都添加了約束，相應(yīng)的插入操作的性能也會(huì)受到影響。
- 即使進(jìn)行了分區(qū)，如果查詢(xún)的條件字段和分區(qū)列并沒(méi)有關(guān)聯(lián)，性能也未必會(huì)得到提升。
it知識(shí)庫(kù)：SqlServer 性能優(yōu)化——Partition（創(chuàng)建分區(qū)），轉(zhuǎn)載需保留來(lái)源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
