我們都知道在數據庫數據量較多的時(shí)候,可數據進(jìn)行水平擴展,如分庫,分區,分表（也叫分區）等。對于分表的一個(gè)方案,就是使用分區視圖實(shí)現。
分區視圖允許將大型表中的數據拆分成較小的成員表。根據其中一列中的數據值范圍，在各個(gè)成員表之間對數據進(jìn)行分區。每個(gè)成員表的數據范圍都在為分區依據列指定的 CHECK 約束中定義。然后定義一個(gè)視圖，以使用 UNION ALL 將選定的所有成員表組合成單個(gè)結果集。引用該視圖的 SELECT 語(yǔ)句為分區依據列指定搜索條件后，查詢(xún)優(yōu)化器將使用 CHECK 約束定義確定哪個(gè)成員表包含相應行。
CHECK 約束 在查詢(xún)方面提供更好的優(yōu)化特性，看一位大俠的實(shí)驗 SQL Server中使用Check約束提升性能 ，當前在其他操作方面就不太好了，以下測試。
當前測試為本地分區視圖：
- USE [DemoDB]
- GO
-
- -- 創(chuàng )建結構相同的表，[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
-
- -- 約束每個(gè)表的范圍
- 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
-
-
- -- 每個(gè)字段名稱(chēng)列出，避免用星號，否則升級增刪字段不同時(shí)會(huì )出錯
- -- 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]
- -- 現在對視圖查詢(xún)
- 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范圍
上面可以看到，只要查詢(xún)在 check 約束范圍內，就會(huì )進(jìn)行查找。第三個(gè)查詢(xún)不在范圍內，并沒(méi)有掃描表行數，只進(jìn)行了常量掃描，這樣提高了查詢(xún)性能。
現在執行視圖更新：
- 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 request_session_id=@@SPID
- COMMIT TRAN
id = 3000 在表 [DemoTab01] 中，對視圖的查詢(xún)轉化為對表的查詢(xún)，但是其他表則都加上了意向排它鎖（IX），這樣在大量并發(fā)中勢必影響到其他用戶(hù)的訪(fǎng)問(wèn)。
執行計劃中，不符合條件的都進(jìn)行了常量掃描，實(shí)際并不讀取數據，但也增加了開(kāi)銷(xiāo)。
關(guān)于垂直拆分，參考 SqlServer 垂直分表
