Sle*_*lee 6 sql-server partitioning sql-server-2012
我的数据库设置了我们所说的临时表和活动表。目前，我们有大约 200 万行用于名为 products 的表。我们称为制造商的客户将他们的数据加载到临时表中，当他们完成更新、添加、删除数据时，我们会将这些数据推送到我们的实时表中。
这些实时表格为移动应用程序和网站提供网络服务。将数据从 staging 推送到 live 包括删除 live 表中的所有数据和插入 staging 表中的所有数据。所有这些都由ManufacturerID存在于每个表中的一个名为的列分隔。
有些制造商有 500 种产品，有些制造商有 75,000 种产品。基于这一点，我们有时会因为对所有 200 万条记录进行分页而导致 Web 服务响应非常缓慢。从实时表中删除数据似乎也变得非常缓慢。
通过ManufacturerID帮助这种情况来分区我的产品表吗？从我读到的内容来看，这基本上意味着当我查询我的产品时，我只会查询数据库的一小部分，ManufacturerID因此整体响应时间有了巨大的改善。
Rem*_*anu 13
不。分区不会加快速度。您的表在分区前有 200 万条记录，分区后将继续拥有完全相同的 200 万条记录。如果您只想查看记录的一小部分，请使用索引。看起来您的数据确实是一个多租户模式，租户密钥是ManufacturerID. 在这种情况下，最有可能的设计是让ManufacturerID成为聚集索引中的前导键。顺便说一句，我推荐阅读多租户数据架构。
分区将有助于涉及快速数据切入和切出的场景，或者在需要将数据分发到不同物理路径（文件组）的场景中。一个很好的阅读是如何决定是否应该使用表分区。
在您说“但是分区消除呢？”之前 我会这样说：几乎没有分区消除可以做的索引不能做得更好。更不用说分区消除是一个彩票，而对聚集索引中前导键的范围扫描几乎是一个坐鸭。此外，每个分区将有多少租户？你将如何均匀分布它们，考虑它们看起来有多不平衡？同样，通过聚集索引中的前导键可以更好地解决这两个问题。并且，尤其要考虑分区带来的巨大设计更改（例如，告别唯一/主键约束或引入未对齐的索引），请参阅分区索引的特殊指南，请特别注意“内存限制”部分。
分区是一个很棒的特性，但不是一个性能特性。分区可以提供帮助的一个示例是对暂存数据进行非常快速的切换（这是您提出的问题），但这将需要每个制造商一个分区，并且它不会扩展，假设每个“制造商”是您公司的客户（租户）。