多个查询以避免连接？答案

【问题标题】：Multiple queries to avoid joins?多个查询以避免连接？
【发布时间】：2009-02-28 16:50:11
【问题描述】：

我已经注意到，一旦我将连接添加到我的一些查询中，执行这些连接所花费的时间不仅仅是完成多个查询。

时间包括页面加载和平均超过 20 个页面加载。

7-9 个没有连接的查询
159毫秒

带有 2 个连接的 3 个查询
235毫秒

考虑到它们似乎对性能有如此重大的影响，我是否应该继续进行多个查询而不是连接？我什至可以优化多查询方法，因为在这些测试期间我什至延迟加载。

编辑

为了这个问题，我将创建一些虚假信息。

表格对象
ID（整数、身份、PK、聚集索引）
用户 ID（int，非聚集索引）
CategoryID (int, 非聚集索引)

表用户
ID（int、identity、PK、聚集索引）

表格分类
ID（int、identity、PK、聚集索引）

很简单。这是对 Objects 表的双重内连接查询。分别查询所有 3 个似乎比连接更快。

连接的查询计划显示 42% 完成了 2 次聚集索引搜索，23% 是聚集索引扫描，其余的是 Top N 排序。

【问题讨论】：

也许发布麻烦的查询会有所帮助...
您是否测试了您提供给我们的虚假架构，以确保它也遇到了减速？

标签： sql linq-to-sql

【解决方案1】：

如果您无缘无故地进行连接，当然可以。通常，您加入表的原因是能够提取相关数据并进行处理。您上面的问题也没有考虑到您需要将这些数据重新组合在一起的编程时间（可能通过循环结构或类似的东西）。

查询分析应该是这里的第一步。我对您的特殊 SQL 风格不是很熟悉，但它可能类似于 EXPLAIN。

如果我必须根据我在这里的有限信息给出一个可能的罪魁祸首，那就是缺少索引。您加入的字段是否已正确编入索引？这可以获得巨大的性能提升。第二，你加入合适的领域了吗？例如，如果您将两个字符串连接在一起，您的性能将比连接整数或其他优化字段差得多。

【讨论】：

我正在加入 int 标识列的聚集索引。是的，它用于通过 LINQ to SQL 查询将相关数据汇集在一起。
哦，就页面加载而言，我还尝试对数据访问时间进行计时，平均为 47 毫秒到 75 毫秒

【解决方案2】：

不，您实际上应该尝试另辟蹊径。您应该尽量减少查询。如果做得正确，那是最快的。

检查表上是否有正确的索引。例如，对于这样的查询：

select a.Some, b.Other
from TableA a
inner join TableB b on b.Id = a.Id

您应该确保 TableB.Id 字段上有索引。表的主键一般默认获取索引，其他索引需要自己创建。

【讨论】：

【解决方案3】：

我建议您查看实际的查询计划并了解响应不同的原因。也许它会突出显示添加索引的表扫描建议？

进行联接更昂贵。但这并不意味着您不应该使用它们。

有助于查看您正在编写的 SQL...（由 LINQ to SQL 生成）

【讨论】：

很遗憾我无法共享 SQL。

【解决方案4】：

您是否尝试过通过分析器使用联接运行查询，看看您是否做了任何事情来优化它们？

【讨论】：

【解决方案5】：

如果您运行这些只是为了在查询分析器中获取数据，那么多个查询就可以了，但如果您从 Web 应用程序或控制台应用程序运行它们，那么您需要优化为 1 个查询。即使需要更长的时间，您也会看到性能上的提升，因为您不会多次访问数据库。您访问数据库的次数越少，您的前端性能就越好。我会努力重新做你的查询，只做一个。看起来您的表已经足够规范化和索引，您应该能够将其归结为一个查询。

【讨论】：

它在网络应用程序中运行，我想一旦我获得大量流量，我可能会看到不同的结果。

【解决方案6】：

我会尝试摆脱所有典型的连接。比如我要修改：

select t1.id, t1.name, t2.gpa from t1 join t2 on t1.id =t2.id

通过这个：

select t1.id, t1.name, t2.gpa from t1, t2 where t2.id = t1.id

【讨论】：

这是笛卡尔连接，最糟糕的连接吗？
不，@hope_is_grim 笛卡尔连接是没有“where”子句的交叉连接