我們都知道在資料庫資料量較多的時候,可資料進行水平擴充套件,如分庫,分割槽,分表（也叫分割槽）等。對於分表的一個方案,就是使用分割槽檢視實現。

分割槽檢視允許將大型表中的資料拆分成較小的成員表。根據其中一列中的資料值範圍，在各個成員表之間對資料進行分割槽。每個成員表的資料範圍都在為分割槽依據列指定的 CHECK 約束中定義。然後定義一個檢視，以使用 UNION ALL 將選定的所有成員表組合成單個結果集。引用該檢視的 SELECT 語句為分割槽依據列指定搜尋條件後，查詢優化器將使用 CHECK 約束定義確定哪個成員表包含相應行。

CHECK 約束 在查詢方面提供更好的優化特性，看一位大俠的實驗

當前測試為本地分割槽檢視：

USE [DemoDB]
GO

--	建立結構相同的表，[id] 不要設定自增（IDENTITY(1,1) ），因為插入表前就需要知道id值
--	DROP TABLE [DemoTab01],[DemoTab02],[DemoTab03]
CREATE TABLE [dbo].[DemoTab01](
	[id] [int] NOT NULL,
	[insdate] [datetime] NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[DemoTab02](
	[id] [int] NOT NULL,
	[insdate] [datetime] NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[DemoTab03](
	[id] [int] NOT NULL,
	[insdate] [datetime] NULL
) ON [PRIMARY]
GO

--	約束每個表的範圍
ALTER TABLE [dbo].[DemoTab01] WITH CHECK ADD CONSTRAINT [CK_DemoTab01_id] CHECK ([id] BETWEEN 0 AND 99999 )
GO
ALTER TABLE [dbo].[DemoTab02] WITH CHECK ADD CONSTRAINT [CK_DemoTab02_id] CHECK ([id] BETWEEN 100000 AND 199999 )
GO
ALTER TABLE [dbo].[DemoTab03] WITH CHECK ADD CONSTRAINT [CK_DemoTab03_id] CHECK ([id] BETWEEN 200000 AND 299999 )
GO

--	既然是按id劃分，把id作為聚集索引更容易定位查詢
ALTER TABLE [dbo].[DemoTab01] ADD CONSTRAINT [PK_DemoTab01_id] PRIMARY KEY CLUSTERED ([id] ASC)
GO
ALTER TABLE [dbo].[DemoTab02] ADD CONSTRAINT [PK_DemoTab02_id] PRIMARY KEY CLUSTERED ([id] ASC)
GO
ALTER TABLE [dbo].[DemoTab03] ADD CONSTRAINT [PK_DemoTab03_id] PRIMARY KEY CLUSTERED ([id] ASC)
GO


--	每個欄位名稱列出，避免用星號，否則升級增刪欄位不同時會出錯
--	DROP VIEW [dbo].[V_DemoTab]
CREATE VIEW [dbo].[V_DemoTab]
AS
SELECT [id],[insdate] FROM [dbo].[DemoTab01]
UNION ALL
SELECT [id],[insdate] FROM [dbo].[DemoTab02]
UNION ALL
SELECT [id],[insdate] FROM [dbo].[DemoTab03]
GO

--	121317行資料
INSERT INTO [V_DemoTab]([id],[insdate])
SELECT SalesOrderDetailID,ModifiedDate FROM AdventureWorks2012.Sales.SalesOrderDetail
GO


SELECT COUNT(*) FROM [dbo].[V_DemoTab]
SELECT COUNT(*) FROM [dbo].[DemoTab01]
SELECT COUNT(*) FROM [dbo].[DemoTab02]
SELECT COUNT(*) FROM [dbo].[DemoTab03]
 

--	現在對檢視查詢
SELECT * FROM [dbo].[V_DemoTab] WHERE id = 0 --不存在
SELECT * FROM [dbo].[V_DemoTab] WHERE id = 3000 --只有該id有記錄
SELECT * FROM [dbo].[V_DemoTab] WHERE id = 300000 --超出check範圍

上面可以看到，只要查詢在 check 約束範圍內，就會進行查詢。第三個查詢不在範圍內，並沒有掃描錶行數，只進行了常量掃描，這樣提高了查詢效能。

現在執行檢視更新：

BEGIN TRAN
	UPDATE [dbo].[V_DemoTab] SET insdate = '2005-11-01' WHERE id = 3000

	select CASE resource_type WHEN 'OBJECT' THEN OBJECT_NAME(resource_associated_entity_id) ELSE '' END AS [object]
	,resource_type,resource_description,request_mode,request_status,request_type
    from sys.dm_tran_locks where resource_database_id=DB_ID() and 
 
[email protected]@SPID  
COMMIT TRAN

id = 3000 在表 [DemoTab01] 中，對檢視的查詢轉化為對錶的查詢，但是其他表則都加上了意向排它鎖（IX），這樣在大量併發中勢必影響到其他使用者的訪問。

執行計劃中，不符合條件的都進行了常量掃描，實際並不讀取資料，但也增加了開銷。

參考：