当不涉及日期时，分区是否有意义？

Question

我们正在讨论根据快速增长的大小对 SQL Server 2008 中的某些应用程序表进行分区。一个是事件表，通常用于 INSERTS（80% 的查询）或 SELECTS 查找表的主键（20% 的查询）。另一个表是一个“映射”表，它是所有查找主键的 SELECTS。

沿着主键的分区在这里会有帮助吗？我读了很多书，所有经典的分区示例似乎都是按日期分区的数据仓库表。似乎分区有时弊大于利。

你觉得这些表怎么样？

Answer 1

您没有解释为什么要对表进行分区以及对分区有何期望。您只提到表大小，这几乎不是分区的标准。性能明智的分区将使一切变得更慢，而不是更快。您所能希望的最好结果是与未分区表的性能相当。一些对分区有意义的场景是：

• ETL 需要像加载作业一样在临时表中密集操作数据，然后在一个快速操作中切换整个临时表
• 需要删除大量已过保留期的数据（每月切换并截断）
• 管理原因，例如需要重建单个分区

许多引用原因，例如“将旧数据移动到较慢的磁盘”，但我不太认同这种说法。另一个经常引用的原因是将数据分布在多个文件中，但这是错误的想法，因为文件组可以包含跨多个卷的多个文件，并且引擎无论如何都会在没有任何分区需求的情况下跨它们分配 IO 。

您提到您的开发人员在按数据分区提高性能时引用了一个案例。也许是一个时间序列数据的情况，它是由id而不是由聚集的，date并且其中所有范围查询（时间序列的典型）都必须进行表扫描。分区似乎有所帮助，因为分区消除减少了扫描的数据量。但是一个合适的聚集索引可以更好地解决这个问题（毫不奇怪，索引通常是查询性能问题的正确答案）。

分区有用的一个极端情况是散列分区以帮助扩展插入最后一页锁存器争用。

但是，当推来推去时，分区是一种“全有或全无”的方法，它具有非常大的影响（考虑到您不能再拥有不包含分区字段的唯一主键）并渗透数据无处不在的模型（例如，必须重新设计很多外键）。它需要谨慎的管理。查询优化器可能会在存在分区的情况下执行一些可怕的计划。

Kendra Little 有一篇很好的文章解释了利弊：如何决定是否应该使用表分区