您是否遇到过 SQL Server 无法执行的查询，因为它引用了太多表？

Question

你见过任何错误信息吗？

-- SQL Server 2000

无法为视图或函数解析分配辅助表。
已超出查询中的最大表数 (256)。

-- SQL Server 2005

查询中的表名过多。 最大允许值为 256。

如果是，你做了什么？

放弃了？ 说服客户简化他们的需求？ 对数据库进行非规范化？

---

@（每个人都希望我发布查询）：

1. 我不确定是否可以在答案编辑窗口中粘贴 70 KB 的代码。
2. 即使我可以这样做，这也无济于事，因为这 70 KB 的代码将引用 20 或 30 个视图，我也必须发布这些视图，否则代码将毫无意义。

我不想听起来像我在这里吹嘘，但问题不在于查询。 查询是最优的（或至少几乎是最优的）。 我花了无数个小时优化它们，寻找可以删除的每一列和每一个表。 想象一个有 200 或 300 列的报表，必须用单个 SELECT 语句填充（因为这是几年前设计的，当时它还是一个小报表）。

Answer 1

对于 SQL Server 2005，我建议您使用表变量并随时构建部分数据。

为此，请创建一个表变量，该变量表示要发送给用户的最终结果集。

然后找到您的主表（例如上面示例中的订单表）并提取该数据，再加上一些补充数据，这些数据仅表示一次连接（客户名称、产品名称）。 您可以执行 SELECT INTO 将其直接放入表变量中。

从那里，遍历表，对每一行，执行一堆小的 SELECT 查询，检索结果集所需的所有补充数据。 随时将这些插入到每一列中。

完成后，您可以从表变量中执行简单的 SELECT * 并将此结果集返回给用户。

我对此没有任何确切的数字，但迄今为止我已经处理了三个不同的实例，在这些实例中，执行这些较小的查询实际上比执行具有一堆连接的大型选择查询更快。

Answer 2

我从未遇到过这种情况，老实说，在查询中引用 > 256 个表的想法让我感到非常恐惧。

你的第一个问题应该可能是“为什么这么多？”，紧随其后的是“什么位的信息做我不需要？” 我担心从这样的查询返回的数据量也会开始严重影响应用程序的性能。

Answer 3

@chopeen您可以更改计算这些统计数据的方式，而是保留一个单独的表格，其中包含所有每个产品的统计数据......下订单时，遍历产品并更新统计数据表中的相应记录。 这会将大量计算负载转移到结帐页面，而不是在运行报告时在一个庞大的查询中运行所有内容。 当然，有些统计数据不会以这种方式工作，例如在购买特定产品后跟踪客户的下一次购买。

Answer 4

在为在 SQL Server 2000 上运行的 Dynamics CRM 安装编写 Reporting Services 报告时，这种情况会一直发生。CRM 有一个很好的规范化数据架构，这会导致大量联接。 实际上有一个修补程序可以将限制从 256 提高到惊人的 260： http : //support.microsoft.com/kb/818406 （我们一直认为这是 SQL Server 团队的一个很好玩的笑话）。

正如 Dillie-O 提到的，解决方案是确定适当的“子连接”（最好是多次使用的），并将它们分解为临时表变量，然后在主连接中使用。 这是一个主要的 PIA，经常会影响性能。 我为你感到难过。

@Kevin，喜欢那件 T 恤——说明一切:-)。

Answer 5

我想看到那个查询，但我想它是某种迭代器的问题，虽然我想不出任何可能的情况，但我敢打赌它来自一个糟糕的 while/case/cursor 或大量执行不力的意见。

Answer 6

发布查询：D

此外，我觉得其中一个可能的问题可能是有大量（读取 200 多个）名称/值表，这些表可以压缩为单个查找表。

Answer 7

我有同样的问题......我的开发盒运行 SQL Server 2008（视图工作正常）但在生产中（使用 SQL Server 2005）视图没有。 我最终创建了视图以避免此限制，将新视图用作引发错误的视图中查询的一部分。

考虑到逻辑执行是一样的，这有点愚蠢......

Answer 8

当我想创建视图时，在 SQL Server 2005（在 2008 年工作）中遇到了同样的问题。 我通过创建存储过程而不是视图解决了这个问题。