在SQL Server 2000 数据仓库中使用分区

您应该看到查询计划中仅包括表 1999。将该查询计划与主键已删除的相同表生成的查询计划相比较，我们会发现：表 2000 仍然被排除。将这些计划与在已删除 date_key 约束的架构上生成的查询计划进行对比。这些约束被删除的情况下，表 1999 和表 2000 都被包括在查询中。

请注意，在通常情况下，在大型表上执行查询时，使用“TOP N”语法是好的做法，因为它可以迅速返回结果并使用最少的服务器资源。查看分区表的查询计划时，这一点尤为重要，因为由“SELECT *”语句生成的查询计划很难解析。对于偶尔进行观察的人而言，尽管在查询执行期间，查询中仅使用相关的表，但表面看起来好象查询计划包括了 UNION ALL 视图的所有组件表。

将条件直接应用于事实表:

要获得最佳的查询性能，所有的查询都应将条件直接放在事实表中的筛选键上。将约束放在第二张表（例如日期矢量表）的查询将包括所有分区。对 UNION ALL 事实表的标准星号联合查询工作良好,将条件放在任意未分区的矢量表的属性上，以标准方式创建星号查询 WHERE 子句,包括分区矢量（日期）的属性。

在分区矢量架构上设计查询与在未分区的架构上设计完全一样，只不过将日期条件直接放在事实表中的日期键上时日期条件最为有效。

如果每一分区表的索引中的第一个列为带日期的簇索引，转到所有分区解析某一特定查询的开销相对较小。编写预定义的查询时应尽可能提高其效率，例如那些生成标准报表或渐变更新下行数据流数据库的查询。

分区键的选择

事实表可以在多个矢量上进行分区，但是大多数人可能仅按日期进行分区。如前面描述的，日期分区可以支持简单的“滚动窗口”管理, 较旧的分区甚至可以被保存在不同的位置，或者减少索引次数。同样，大多数对数据仓库的查询是按日期进行筛选的。

对于按日期分区的应用程序，决策变量为：

使多少数据保持联机状态？这项决策的主要依据是业务要求，同时要考虑保持大量数据联机的费效比。

如何设计日期键？数据仓库最好对矢量表和事实表使用代理键，这是得到广泛认可的。对于按日期分区的事实表，建议的做法为使用 yyyymmdd 形式的“智能”整数代理键。作为整数，与 8 字节的 datetime 相比较，该键仅使用 4 个字节。许多数据仓库使用 datetime 类型的自然日期键。

如何确定分区的大小？尽管上面的示例使用年分区，但大多数系统会划分得更细致，例如月、星期或天。尽管我们会注意到用户查询通常是按月或周进行的，但最重要的因素还是系统总体规模和可管理性。您可能还记得，任何一个 SQL 查询最多可以引用 256 张表。对于维护多于一个月的数据的数据仓库，按天来分区的 UNION ALL 视图会超过该界限。作为一个好的规则，如果事实表仅按日期分区，那么最好按星期分区。

定义分区的范围

BETWEEN 语法最直接、可读性最强、执行效率最高。以下述形式的按月分区为例：

date_key < 19990101
date_key BETWEEN 1990101 AND 19990131
date_key BETWEEN 19990201 AND 19990229
...
date_key BETWEEN 19991201 AND 19991231
date_key > 19991231

请注意其中的第一个和最后一个分区：即使您认为决不会有数据进入这些分区，这仍是一个定义分区的好方法，这样可以覆盖所有可能的日期值。同时，请注意尽管 1999 年不是闰年，但二月分区仍覆盖 2 月 29 日。该结构使设计创建分区和约束的应用程序时不需要判断是否为闰年。

随着时间流逝，要合并分区吗？为了使活动分区的数量最小，创建分区应用程序时，数据库管理员可以选择将日分区合并为星期分区或月分区。我们将在下面有关填充和维护分区的一节中详细讨论这种方法。