我正在用ssrs编写一个报表，并在后端运行一个半大型的sqlserver查询。我的查询有大约10-15个子查询，并且发现其中一些子查询将我的运行时间减慢到用户无法使用的程度（10-15分钟的运行时间）。有没有人对故障排除有什么建议，来找出我的查询中有什么东西减慢了它的执行速度？我想保持它的简单（最好没有附加组件），我只是想针点的问题是这样我就可以重组需要。我是sql server的新手，中等强度的查询编写员。任何使用功能的指针都是非常棒的。提前谢谢！
pxyaymoc1#
正如其他人在没有看到查询的情况下所说的，很难给出具体的建议，但是正如您所提到的，它有10-15个子查询，那么这可能是问题的一部分，特别是如果这些子查询有where子句的话。例如，如果你有
SELECT * FROM myTable a JOIN (SELECT * FROM AnotherTable WHERE aColumn = @aValue) b ON a.SomeColumn = b.SomeColumn
如果子查询中的表很大或索引很差，则这可能会很慢。一个快速的测试和潜在的快速胜利是将子查询结果写入一个临时表并连接到该临时表上，这样同一个查询将如下所示。。。
SELECT * INTO #temp FROM AnotherTable WHERE aColumn = @aValue SELECT * FROM myTable a JOIN #temp b ON a.SomeColumn = b.SomeColumn
vzgqcmou2#
一个好的起点是使用“display estimated execution plan”（ctrl+l）在ssms中执行相同的查询。这将解析查询并为您提供一个查询计划，您可以检查该计划以查看哪些地方使用了大量cpu和/或io。您还可以在启用“实际执行计划”的情况下在ssms中执行相同的查询。这将执行查询并给出实际运行的内容。通常估计值和实际值是相同的，但并不总是相同的。从estimated开始，因为您不必等待查询完成。查找大表扫描和缺少的索引。这些通常是最大的罪魁祸首。
2条答案
按热度按时间pxyaymoc1#
正如其他人在没有看到查询的情况下所说的，很难给出具体的建议，但是正如您所提到的，它有10-15个子查询，那么这可能是问题的一部分，特别是如果这些子查询有where子句的话。
例如，如果你有
如果子查询中的表很大或索引很差，则这可能会很慢。
一个快速的测试和潜在的快速胜利是将子查询结果写入一个临时表并连接到该临时表上，这样同一个查询将如下所示。。。
vzgqcmou2#
一个好的起点是使用“display estimated execution plan”（ctrl+l）在ssms中执行相同的查询。这将解析查询并为您提供一个查询计划，您可以检查该计划以查看哪些地方使用了大量cpu和/或io。
您还可以在启用“实际执行计划”的情况下在ssms中执行相同的查询。这将执行查询并给出实际运行的内容。通常估计值和实际值是相同的，但并不总是相同的。从estimated开始，因为您不必等待查询完成。
查找大表扫描和缺少的索引。这些通常是最大的罪魁祸首。