本篇文章是我在:看到了，如我们所知，大家在介绍表分区的时候一直在歌颂其好处。但一句古谚语说的好，每个人都有其阴暗面，表分区也会在特定情况下反而降低其性能。
例子
首先建立测试表,并在其上建立聚集索引:
dbo.Orders ( Id , OrderDate , DateModified , Placeholder (500) Def_Data_Placeholder 'Placeholder', ); IDX_Orders_Id dbo.Orders(ID);
代码1，创建测试表
然后插入测试数据:
N1 ( C ) ( 0 0 )-- 2 rows, N2 ( C ) ( 0 N1 T1 N1 T2 )-- 4 rows, N3 ( C ) ( 0 N2 T1 N2 T2 )-- 16 rows, N4 ( C ) ( 0 N3 T1 N3 T2 )-- 256 rows, N5 ( C ) ( 0 N4 T1 N4 T2 )-- 65,536 rows, N6 ( C ) ( 0 N5 T1 N2 T2 N1 T3 )-- 524,288 rows, IDs ( ID ) ( ROW_NUMBER() ( ( ) ) N6 ) * IDs dbo.Orders ( ID , OrderDate , DateModified ) ID , DATEADD(, 35 * ID, @StartDate) , ID % 10 = 0 DATEADD(, 24 * 60 * 60 * ( ID % 31 ) + 11200 + ID % 59 + 35 * ID, @StartDate) DATEADD(, 35 * ID, @StartDate) IDs;
代码2.插入测试数据
插入测试数据的代码貌似复杂，其实只是通过递归CTE的办法生成自1开始的数字，然后为每一个行插入略微递增的日期。对于modifyDate列，每10个记录插入一个略微大的值。此时执行如下查询:
图1.没有分区的查询计划，看起来不错
对应的，得到的统计信息:
(100 行受影响)
表 'Orders'。扫描计数 1，逻辑读取 310 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。SQL Server 执行时间:
CPU 时间 = 15 毫秒，占用时间 = 756 毫秒。
我们DROP掉上面的索引后，重新进行表分区,如代码3所示:
--drop索引 IDX_Orders_DateModified_Id dbo.Orders; IDX_Orders_Id dbo.Orders;--分区函数 PARTITION pfOrders() RANGE ('2012-02-01', '2012-03-01','2012-04-01','2012-05-01','2012-06-01','2012-07-01','2012-08-01');--分区方案 PARTITION SCHEME psOrders PARTITION pfOrders ([]);--再次创建聚集索引 IDX_Orders_OrderDate_Id dbo.Orders(OrderDate,ID) psOrders(OrderDate);--再次创建非聚集索引 IDX_Data_DateModified_Id_OrderDate dbo.Orders(DateModified, ID, OrderDate) psOrders(OrderDate); 代码3.进行分区
然后，我们通过代码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 次。 Server 执行时间: CPU 时间= 219 毫秒，占用时间= 783 毫秒。
不难看出，性能下降的十分明显。
因此，不要在生产环境中数据量一大就想到表分区。在进行表分区之前，首先考虑一下对分区计划进行测试，否则在生产环境中出现上面的情况就悲剧了。