在生產環境中會遇到這樣的場景,一個表隨着時間的推移,愈來愈大,這個時候咱們開始動手爲這個表創建分區來改進查詢性能。 可是表過大上百個G的時候,在數據倉庫中,爲了改進查詢性能,咱們能夠添加在分區表的基礎之上添加ColumnStore Index, 添加後,瞬間讓10分鐘的查詢變身成幾秒鐘, 這是真實的。 性能
可是,當新的一年開始了,須要爲這個大表添加新的分區,倒是一件很耗時的事情,有一些坑,須要避免:spa
1. 在創建分區之初,若是按時間劃分,則應該一次加上5-10年的,由於後續修改很麻煩it
2. 在有ColumnStore Index的分區表上添加新的分區,步驟以下:io
- 添加新的文件組
- ALTER DATABASE [AdvantureWorks]
ADD FILEGROUP [FG_Email_2020]
GO
- 添加新的文件到相應的文件組中
- ALTER DATABASE [AdvantureWorks]
ADD FILE
(
NAME = [Email_2020],
FILENAME = 'D:\OLTPDatabases\Data\AW_Email2020.ndf',
SIZE = 512KB,
FILEGROWTH = 1024MB
) TO FILEGROUP [FG_Email_2020]
- 刪除全部使用相同partition function的表上的ColumnStore Index
- Drop index CCI_Email on dbo.Email
- 修改Partition Scheme, 添加新的文件組
- ALTER PARTITION SCHEME [EmailYearlyPS]
next used [FG_Email_2020]
go
- 修改Partition Function, split range , 就是添加新的劃分值,若是新的值已經在舊的partition中,則須要先執行split range 把數據傳到新的partition中, 而後再 alter partition scheme. 若是繼續添加split range, 則繼續添加
- ALTER PARTITION FUNCTION [EmailYearlyPF] ()
SPLIT RANGE (20200101)
- 從新建立Column Store Index
-
CREATE CLUSTERED INDEX [CCI_FactClick]
ON [dbo].[FactClick]([ClickId])
ON [EmailYearlyPS] ([EmailGenerationDateKey]);
CREATE CLUSTERED COLUMNSTORE INDEX [CCI_FactClick] ON [dbo].[FactClick] WITH (DROP_EXISTING = ON) ON [EmailYearlyPS] ([EmailGenerationDateKey]);