3

我正在使用的数据库目前超过 100 GiB，并有望在未来一年左右变得更大。我正在尝试设计一个可以与我的数据集一起使用的分区方案，但到目前为止都失败了。我的问题是，针对这个数据库的查询通常会测试这个大表中多个列的值，最终导致结果集以不可预测的方式重叠。

每个人（与我一起工作的 DBA）都警告不要让表超过一定大小，我已经研究和评估了我遇到的解决方案，但它们似乎都依赖于允许逻辑表分区的数据特征。不幸的是，鉴于我的表格结构，我看不到实现这一目标的方法。

这是我们的两个主要表格的结构，以便对此进行透视。

Table: Case
Columns:
Year
Type
Status
UniqueIdentifier
PrimaryKey
etc.

Table: Case_Participant
Columns:
Case.PrimaryKey
LastName
FirstName
SSN
DLN
OtherUniqueIdentifiers

请注意，上面的任何列都可以用作查询参数。

4

3 回答 3

5

与其猜测，不如衡量。收集使用统计信息（查询运行），查看引擎自己的统计信息sys.dm_db_index_usage_stats，然后做出明智的决定：最能平衡数据大小并为最常运行的查询提供最佳亲和力的分区将是一个很好的候选者。当然，你必须妥协。

也不要忘记分区是每个索引（其中“表”=索引之一），而不是每个表，所以问题不是要分区，而是要分区的索引以及要使用的分区函数。显然，您在两个表上的聚集索引将是最有可能的候选者（仅对非聚集索引进行分区而不对聚集索引进行分区没有多大意义）因此，除非您正在考虑重新设计聚集键，否则问题确实是为您的聚集索引选择的分区函数。

如果我冒昧地猜测一下，我会说对于随时间累积的任何数据（例如带有“年份”的“案例”），最自然的分区是滑动窗口。

于 2009-06-11T23:55:15.020 回答
0

如果您没有其他选择，您可以通过 key module 分区表的数量进行分区。假设您要分区到 10 个表。您将定义表：
Case00
Case01
...
Case09

并通过 UniqueIdentifier 或 PrimaryKey 模块 10 对数据进行分区，并将每条记录放在相应的表中（根据您的唯一 UniqueIdentifier，您可能需要开始手动分配 id）。

执行查询时，您需要对所有表运行相同的查询，并使用 UNION 将结果集合并为单个查询结果。

它不如基于与预期查询相对应的一些逻辑分离来对表进行分区，但它比达到表的大小限制更好。

于 2009-06-11T21:02:15.420 回答
0

另一个可能要看的东西（在分区之前）是你的模型。

您在规范化数据库中吗？是否有进一步的步骤可以通过标准化/去/部分标准化中的不同选择来提高性能？是否有选项可以将数据转换为最适合报告/查询的 Kimball 风格的维度星模型？

如果您不打算删除表的分区（如前所述的滑动窗口）或以不同的方式处理不同的分区（您说可以在查询中使用任何列），我不确定您要摆脱什么您还没有脱离索引策略的分区。

我不知道行的任何表限制。AFAIK，行数仅受可用存储空间的限制。

于 2009-06-13T00:07:51.673 回答