如何证明在 SQL 中使用子选择查询会降低服务器性能

发布于 2024-10-09 14:12:41 字数 326 浏览 2 评论 0原文

我的工作之一是维护我们的数据库，通常我们在获取报告和使用该基础工作时会遇到性能不足的问题。
当我开始查看 ERP 发送到数据库的查询时，我看到主查询中有很多完全不必要的子选择查询。
由于我不是我们使用的程序的创建者开发人员的成员，因此当我批评他们的代码和工作时，他们不太喜欢。假设他们不把我的评论视为严肃的陈述。所以我问你几个关于 SQL 中子选择的问题子

选择是否比左外连接花费更多时间？
是否存在任何博客、文章或任何我子选择的内容建议不要使用的内容？
我如何证明如果我们避免在查询中使用 subselesct，查询将会更快？

我们的数据库服务器是MSSQL2005

原文

分享到QQ

分享到微博

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

发布评论

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

橘和柠 2024-10-16 14:12:42

根据我自己的经验，这两种方法都是有效的，例如 EXISTS 子选择可以通过提前中断来避免大量处理。

但大多数时候，带有大量子查询的查询是由开发人员完成的，他们并不真正理解 SQL，并使用他们经典的过程程序员思维方式来进行查询。然后他们甚至不考虑连接，并进行一些糟糕的查询。所以我更喜欢连接，并且总是检查子查询。老实说，我跟踪慢速查询，并且我对包含子选择的慢速查询的第一次尝试是尝试进行连接。工作时间很多。

但是没有任何规则可以确定子选择是坏的或者比连接慢，只是糟糕的 sql 程序员经常做子选择:-)

回复收藏 0 原文

陌伤浅笑 2024-10-16 14:12:42

子选择是否比左外连接花费更多时间？

这取决于子选择和左外连接。

一般来说，这个结构：

SELECT  *
FROM    mytable
WHERE   mycol NOT IN
        (
        SELECT  othercol
        FROM    othertable
        )

比这个更有效：

SELECT  m.*
FROM    mytable m
LEFT JOIN
        othertable o
ON      o.othercol = m.mycol
WHERE   o.othercol IS NULL

请参见此处：

NOT IN 与 NOT EXISTS 与 LEFT JOIN / IS NULL：SQL Server

是否存在建议不要使用 subselect 的博客、文章或任何内容？

我会避开那些盲目建议避免子选择的博客。

它们的实现是有原因的，不管你信不信，开发人员已经付出了一些努力来优化它们。

我如何证明如果我们避免在查询中使用 subselesct，查询将会更快？

编写一个不带子选择的查询，这样运行速度更快。

如果您在这里发布您的查询，我们可能能够对其进行改进。然而，带有子选择的版本可能会更快。

Does subselect is taking a lot of more time then left outer joins?

This depends on the subselect and left outer joins.

Generally, this construct:

SELECT  *
FROM    mytable
WHERE   mycol NOT IN
        (
        SELECT  othercol
        FROM    othertable
        )

is more efficient than this:

SELECT  m.*
FROM    mytable m
LEFT JOIN
        othertable o
ON      o.othercol = m.mycol
WHERE   o.othercol IS NULL

See here:

NOT IN vs. NOT EXISTS vs. LEFT JOIN / IS NULL: SQL Server

Does exists any blog, article or anything where subselect is recommended not to use ?

I would steer clear of the blogs which blindly recommend to avoid subselects.

They are implemented for a reason and, believe it or not, the developers have put some effort into optimizing them.

How I can prove that if we avoid subselesct in query that query is going to be faster ?

Write a query without the subselects which runs faster.

If you post your query here we possibly will be able to improve it. However, a version with the subselects may turn out to be faster.

回复收藏 0 原文

无人接听 2024-10-16 14:12:42

尝试重写一些查询以消除子选择和比较运行时间。

分享并享受。

回复收藏 0 原文

蓝天白云 2024-10-16 14:12:41

“展示，而非讲述”- 检查并比较使用 SQL Profiler 识别的查询的查询计划。特别要注意表扫描和书签查找（您希望尽可能频繁地看到索引查找）。查询计划的“拟合优度”取决于最新的统计信息、定义的索引以及整体查询工作负载。

在 SQL Server Management Studio (SSMS) 中运行查询并打开查询 -> 包含实际执行计划 (CTRL+M)

认为自己很幸运，它们只是子选择（在某些情况下，优化器将生成等效的“连接”）计划'）而不是相关子查询！

识别执行大量逻辑读取的查询，使用您喜欢的技术重新编写它，然后通过比较显示其执行的逻辑读取数量。

这是一个提示。要获取执行的逻辑读取总数，请将有问题的查询包装为：

SET STATISTICS IO ON
GO

-- Run your query here

SET STATISTICS IO OFF
GO

运行查询，然后切换到结果窗格中的消息选项卡。

如果您有兴趣了解更多信息，没有比 SQL Server 2008 查询性能调优更好的书了Distilled，涵盖了监控、解释和修复性能问题的基本技术。

"Show, Don't Tell" - Examine and compare the query plans of the queries identified using SQL Profiler. Particularly look out for table scans and bookmark lookups (you want to see index seeks as often as possible). The 'goodness of fit' of query plans depends on up-to-date statistics, what indexes are defined, the holistic query workload.

Execution Plan Basics
Understanding More Complex Query Plans
Using SQL Server Profiler (2005 Version)

Run the queries in SQL Server Management Studio (SSMS) and turn on Query->Include Actual Execution Plan (CTRL+M)

Think yourself lucky they're only subselects (which in some cases the optimiser will produce equivalent 'join plans') and not correlated sub-queries!

Identify a query that is performing a high number of logical reads, re-write it using your preferred technique and then show how few logicals reads it does by comparison.

Here's a tip. To get the total number of logical reads performed, wrap a query in question with:

SET STATISTICS IO ON
GO

-- Run your query here

SET STATISTICS IO OFF
GO

Run your query, and switch to the messages tab in the results pane.

If you are interested in learning more, there is no better book than SQL Server 2008 Query Performance Tuning Distilled, which covers the essential techniques for monitoring, interpreting and fixing performance issues.

回复收藏 0 原文