Sql server 如何在SQLServer2008R2上实现mod分区？

我可能会在一个巨大的表（数十亿行）上实现分区

每个表行都有关于特定设备的某种状态，每分钟插入一次。因此，每个设备每天将有1440（24 x 60）行。每个设备都有一个唯一的ID（DeviceID）

我考虑过使用DeviceID MOD{TheNumberOfPartitionsThatIWant}进行分区，我认为分区数为250是一个很好的折衷方案。使用这种策略，我可以将设备均匀地分布在各个分区中，而且，当查询特定设备时，查询引擎只需要接触一个分区，而不是所有的250个分区

---

问题是，我需要向表中添加一个额外的列，以指示行所属的分区，这样我就可以使用该列在分区模式上定义表。最好向分区模式提供（DeviceID MOD 250），而不是让此列使用如此简单的表达式。有解决方法吗？

您可以基于一个函数对绑定到模式的计算列进行分区-但是，虽然这样做可行，但好处将是有限的，我希望看到对它进行缩放测试。然后，它还要求每个对该表的访问在where条件内使用相同的函数

关键点是由dportas提出的—分区的设计目的是使数据老化成为一个简单的操作，在某些时候，系统中的数据将由于太旧/没有价值而需要清除，此时您将减少到长时间运行的删除以删除此数据

---

就跨多个磁盘传播数据而言，分区不会为现有的文件组/文件设施提供任何显著的额外功能。

适当的索引可能会比分区获得更好的结果。正如@Andrew所说，分区主要用于快速加载和卸载数据（即，切换分区）。我创建了一个计算列，解决了这个问题。

我在您之前的评论中看到您有两个驱动器。使用2个分区。。不如果你想处理这类卷，你根本不会在硬件上节俭。那只是一种体验。在最终的解决方案中，我们可能会使用DAS或SAN配置。分区策略的目的是什么？它是为了在查询中消除分区、支持快速数据加载还是允许有选择地归档旧数据？您可以基于DeviceID对计算列进行分区，以创建250个范围，但考虑到所有分区可能每天都会更新，这显然不是一个合理的分区策略。另外，表的预期大小（MB/GB/天）是多少？目的是在查询中消除分区。但是在我的测试中，分区表上的查询比未分区表上的查询慢。索引是设置好的，它只访问一个分区（我在实际执行计划中检查了它），但速度较慢。为什么？