SQL Server 2005是微软在推出SQL Server 2000后时隔五年推出的一个数据库.相对于SQL Server2000来说有了质的提高。它给我们提供了诸多新特性，例如：复制、分区、动态管理视图、CTE、性能顾问等等。
在微软TechNet上是这样介绍分区表和分区索引的：
Instruction 已分区表和已分区索引的数据划分为分布于一个数据库中多个文件组的单元。数据是按水平方式分区的，因此多组行映射到单个的分区。对数据进行查询或更新时，表或索引将被视为单个逻辑实体。单个索引或表的所有分区都必须位于同一个数据库中。
已分区表和已分区索引支持与设计和查询标准表和索引相关的所有属性和功能，包括约束、默认值、标识和时间戳值以及触发器。因此，如果要实现位于服务器本地的已分区视图，则可能需要改为实现已分区表。
决定是否实现分区主要取决于表当前的大小或将来的大小、如何使用表以及对表执行用户查询和维护操作的完善程度。
通常，如果某个大型表同时满足下列两个条件，则可能适于进行分区：
该表包含(或将包含)以多种不同方式使用的大量数据。
不能按预期对表执行查询或更新，或维护开销超过了预定义的维护期。
例如，如果对当前月份的数据主要执行 INSERT、UPDATE 和 DELETE 操作，而对以前月份的数据主要执行 SELECT 查询，则如果按月份对表进行分区，表的管理可能要容易些。如果对表的常规维护操作只针对一个数据子集，那么此优点尤为明显。如果该表没有分区，那么就需要对整个数据集执行这些操作，这样就会消耗大量资源。例如，通过分区，可以针对具有只写数据的单个月份执行类似索引重新生成和碎片整理的维护操作，而只读数据仍可用于联机访问。 正如上面的描述，分区为可以将对数据的操作压力分散到各个分区文件组中，应用程序每次访问的数据只是在某个数据分区上，这样可以相应的提高数据库的性能。
找个了数据量在200W左右的表，这个表是一个账本类型的表，可以以时间日期作为分区依据列，将200W数据依据月份分配到12个分区上。然后执行业务存储过程进行测试：
SP exec proc_partitiontest @HCompany=N’0002’,@HOrg=N’00000000000000000223’,
@FiscalYear=N’2008’,@FiscalPeriod=N’01’,
@HWareHouseID=N’’,@SpeStock=N’’,@ofObject=N’’ ,......
执行结果比较：
分区前：执行时间52s ，IO cost：
Table 'PartitionAccount'. Scan count 2, logical reads 1735, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
分区后：执行时间47s ，IO cost：
Table 'PartitionAccount'. Scan count 2, logical reads 76, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
对性能提高很一般，是数据量较少的原因么?还是查询应用分区键不太合理?因为一些原因，这个sp的具体写法不能贴出，请各位朋友谅解。在这里，请朋友们谈谈分区的关键，谢谢。