对于 SQL Server 2005 中的表分区,收益递减定律在哪里发挥作用?

发布于 2024-08-19 18:19:13 字数 145 浏览 6 评论 0原文

我想知道是否有人在 sql server 2005 中遇到过实际的最大表分区数。我知道文档声明每个表的分区数限制为 1000 个,但我很难相信这一点,如果没有经过大量的修改和修改,1000 个分区就足够了。

任何帮助表示赞赏。

韦恩·E·普费弗

I'm wondering if anyone out there has run into a realistic max number of table partitions in sql server 2005. I know that the docs state that there is a limit of 1000 partitions per table, but I have a hard time believing that, without a lot of hacking and mucking about, that 1000 partitions would be all that usable.

Any help is appreciated.

Wayne E. Pfeffer

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

牵你的手,一向走下去 2024-08-26 18:19:13

您很可能会编写操作脚本,因此如果您需要 1000 个分区,那么这不会是管理问题。更多分区=更小的分区。因此,如果您有大量数据,那么拥有更多分区可能会很有用。

但是,当您开始接近这些限制(例如列数限制或与硬件无关的其他此类最大值)时,您可能需要开始重新考虑您的设计。

You would most likely script your operations, so if you NEEDED 1000 partitions, it wouldn't be a management problem. More partitions = smaller partitions. So if you have mega huge data, having more partitions could be useful.

However, when you start approaching these limits - like column # limits or other such maximums not related to hardware, you might want to start rethinking your design.

腹黑女流氓 2024-08-26 18:19:13

从另一种方式开始 - 询问 2 个分区是否太多。您想知道您的查询是否会消除分区。 SQL Server 2005 的分区消除性能不太好,如果 WHERE 子句中没有分区字段,SQL Server 通常会扫描每个分区。例如,如果我的 SalesDetail 表根据 CustomerID 进行分区,则这可能不会进行分区消除:

SELECT *
  FROM dbo.SalesReps sr
  INNER JOIN dbo.Customers c ON sr.SalesRepID = c.SalesRepID
  INNER JOIN dbo.Sales s ON c.CustomerID = s.CustomerID
  WHERE sr.SalesRepID = 10

即使 SalesRep 10 只有几个客户,引擎也不够智能,无法首先构建匹配客户的列表,然后仅查询这些客户的销售分区。它会击中每个分区。因此,我建议确保您的分区方案完全适用于您的 SELECT 查询,然后如果可以,请使用它运行。分区的细化程度越高,读取查询在消除分区时运行的速度就越快。

Start the other way - by asking if 2 partitions is too much. You want to find out if your queries will do partition elimination at all. SQL Server 2005's partition elimination doesn't perform too well, and if you don't have the partitioned fields as part of your WHERE clause, SQL Server often scans every partition anyway. For example, if I've got my SalesDetail table partitioned on CustomerID, this may not do partition elimination:

SELECT *
  FROM dbo.SalesReps sr
  INNER JOIN dbo.Customers c ON sr.SalesRepID = c.SalesRepID
  INNER JOIN dbo.Sales s ON c.CustomerID = s.CustomerID
  WHERE sr.SalesRepID = 10

Even though SalesRep 10 only has a couple of customers, the engine isn't smart enough to build the list of matching customers first, then only query the Sales partitions for those customers. It's gonna hit every partition. So I'd recommend making sure your partitioning scheme works at all for your SELECT queries, and then if so, run with it. The more tightly refined you can get your partitions, the faster your read queries will run when they eliminate partitions.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文