您是否见过任何错误消息？
-- SQL Server 2000
无法为视图或函数解析分配辅助表。
已超出查询中的最大表数 (256)。-- SQL Server 2005
查询中的表名过多。允许的最大值为 256。
如果是，你做了什么？
放弃了？说服客户简化他们的需求？非规范化数据库？
@（希望我发布查询的每个人）：
我不想听起来像我在这里吹嘘，但问题不在于查询。查询是最佳的（或至少几乎是最佳的）。我花了无数个小时优化它们，寻找可以删除的每一列和每一个表。想象一个包含 200 或 300 列的报表，必须用单个 SELECT 语句填充（因为几年前它还是一个小型报表时就是这样设计的）。
对于 SQL Server 2005，我建议您使用表变量并随时构建部分数据。
为此，请创建一个表变量，该变量代表您要发送给用户的最终结果集。
然后找到您的主表（例如上面示例中的订单表）并提取该数据，加上一些补充数据，仅表示一次连接（客户名称，产品名称）。您可以执行 SELECT INTO 将其直接放入表变量中。
从那里，遍历表并为每一行执行一堆小的 SELECT 查询，检索结果集所需的所有补充数据。随时将这些插入每一列。
完成后，您可以从表变量中执行简单的 SELECT * 并将此结果集返回给用户。
我对此没有任何确切的数字，但是到目前为止，我已经处理了三个不同的实例，其中执行这些较小的查询实际上比执行带有一堆连接的大规模选择查询更快。
我从来没有遇到过这种情况，老实说，在查询中引用 > 256 个表的想法让我充满了致命的恐惧。
您的第一个问题可能应该是“为什么这么多？”，紧随其后的是“我不需要哪些信息？ ” 我担心从这样的查询返回的数据量也会开始严重影响应用程序的性能。
@chopeen您可以更改计算这些统计信息的方式，而是保留所有每个产品统计信息的单独表格。下订单时，循环浏览产品并更新统计信息表中的适当记录。这会将大量计算负载转移到结帐页面，而不是在运行报告时在一个巨大的查询中运行所有内容。当然，有些统计数据不会以这种方式发挥作用，例如在购买特定产品后跟踪客户的下一次购买。
在为 SQL Server 2000 上运行的 Dynamics CRM 安装编写 Reporting Services 报告时，这种情况总是会发生。CRM 有一个很好的规范化数据架构，它会导致大量的连接。实际上有一个修补程序将限制从 256 提高到惊人的 260： http: //support.microsoft.com/kb/818406（我们一直认为这是 SQL Server 团队的一个很好的笑话）。
正如 Dillie-O 所暗示的那样，解决方案是识别适当的“子连接”（最好是多次使用的）并将它们分解为临时表变量，然后在主连接中使用。这是一个主要的 PIA，经常会影响性能。我为你感到难过。
@Kevin，喜欢那件 T 恤——说明一切 :-)。
我想看看那个查询，但我想这是某种迭代器的问题，虽然我想不出任何可能的情况，但我敢打赌它来自一个糟糕的 while/case/cursor 或大量执行不力的观点。
发布查询：D
此外，我觉得其中一个可能的问题可能是拥有大量（读取 200 多个）名称/值表，这些表可以浓缩成一个查找表。
我遇到了同样的问题...我的开发框运行 SQL Server 2008（视图工作正常），但在生产环境中（使用 SQL Server 2005）视图却没有。我最终创建了视图以避免此限制，在引发错误的视图中使用新视图作为查询的一部分。
考虑到逻辑执行是一样的有点傻......
当我想创建一个视图时，在 SQL Server 2005（2008 年工作）中遇到了同样的问题。我通过创建存储过程而不是视图解决了这个问题。