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

Question

我的工作之一就是维护我们的数据库,通常我们在获取报告和工作时会遇到性能不足的麻烦.
当我开始查看我们的ERP发送到数据库的查询时,我在主查询中看到了很多完全不必要的子查询.
因为我不是我们使用的程序创建者的开发人员,所以当我批评他们的代码和工作时,他们并不喜欢.让我们说他们不把我的评论作为严肃的陈述.所以我问你几个关于SQL中subselect的问题

subselect是否需要花费更多时间才能留下外连接？
是否存在任何博客,文章或我推荐不使用的任何内容？
我怎样才能证明,如果我们在查询中避免使用subselesct查询会更快？

我们的数据库服务器是MSSQL2005

Answer 1

"显示,不要告诉" - 检查并比较使用SQL事件探查器识别的查询的查询计划.特别注意表扫描和书签查找(您希望尽可能多地查看索引查找).查询计划的"适合度"取决于最新统计信息,定义了哪些索引,整体查询工作负载.

• 执行计划基础

• 了解更复杂的查询计划

• 使用SQL Server Profiler(2005版)

在SQL Server Management Studio(SSMS)中运行查询并启用Query-> Include Actual Execution Plan(CTRL + M)

认为自己很幸运,他们只是次选(在某些情况下优化器会生成相应的'连接计划')而不是相关的子查询!

确定执行大量逻辑读取的查询,使用首选技术重新编写它,然后通过比较显示逻辑读取的次数.

这是一个提示.要获取执行的逻辑读取总数,请使用以下命令包装有问题的查询:

SET STATISTICS IO ON
GO

-- Run your query here

SET STATISTICS IO OFF
GO

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

如果您有兴趣了解更多信息,那么没有比SQL Server 2008查询性能调优蒸馏更好的书籍,它涵盖了监控,解释和修复性能问题的基本技术.