问题标签 [sql-execution-plan]

我已经到处寻找这个命令......重置SQL Server的执行计划的命令是什么？

有谁知道可用于比较（相对复杂）查询计划的工具？我不是在寻找查询计划的指南，而只是让我能够快速查看不同索引使用的工具。

编辑：为了清楚起见，我不是在寻找有关计划的信息，而是一种可以快速指出两个计划之间差异的工具（我知道，我可以自己做，但是计划的大小（s ）使这变得困难）。

我有一个查询，我从 5 个左外连接表中的每一个中选择几列。

我在 SQL Server 2008 中做了一个执行计划，基本上对所有连接的表都进行了表扫描，但它们的成本都是 0%——我假设是因为这些表中的记录不多。

然后在执行计划的最后两步（所有表的最终合并连接和实际的 SELECT 语句），它说 55% 的成本是合并连接，45% 的成本是选择。

这对我来说似乎很奇怪......为什么最后 2 个“将所有内容整合在一起”步骤的成本如此之高？我认为所有这些表扫描或排序步骤都会产生更大的成本。

我正在尝试从所有这些表中获取一个“汇总”记录......也许我在左加入所有内容时采取了错误的方法？

用 SQL 更新

只是一个普遍的问题：

执行特定查询时，是否可以将查询/命令传递给 SQL Server 以不使用缓存？

我正在寻找可以设置的查询/命令，而不是配置设置。有没有必要这样做？

我用谷歌搜索了这个问题，似乎找不到一致的意见，或者许多基于可靠数据的意见。我只是想知道在 SQL SELECT 语句中使用通配符是否会比单独调用每个项目产生额外的开销。我在几个不同的测试查询中比较了两者的执行计划，似乎估计值总是相同的。是否有可能在其他地方产生一些开销，或者它们是否真的以相同的方式处理？

我具体指的是：

对比

我有一个简单的数据记录表，其中包含两个数据列 A 和 B，我想为其生成 A+B 的总和。但是，A 和 B 中的一个或两个都可以为空。该表还有一个时间戳列，它是主键

我可以看到几种给这只猫剥皮的方法，但我很想知道在一系列时间戳上汇总数据的首选方法是什么：

我从执行计划程序中得到以下结果：

我以前从未深入研究过查询计划，所以我不确定如何解释这些数字。公平地说，一般来说，总体百分比偏向右侧越多越好吗？使表格 3 优于表格 1 和表格 2？

我有一个复杂的 MySQL 查询，它连接三个表并将一个表自连接到自身。

有一个 Master 和一个 Slave 具有相同的数据和索引。与 Slave 相比，Master 是一个强大的盒子，但查询在 Slave 上的运行速度要快 10 倍（在 Master 的轻负载期间）。

执行计划大不相同。

这些表以不同的顺序处理，主数据库使用临时表和文件排序，而从属仅使用文件排序。

哪些因素会导致执行时间差异如此之大的不同计划？

更新：

这可能与索引统计有关吗？我计划在低容量期间在 Master 上运行 ANALYZE TABLE。SHOW INDEX 显示 Master 和 Slave 之间的某些键的非常不同的基数。

我有一个查询，它创建几个临时表，然后将数据插入其中。据我了解，这是 Table Spool 的潜在原因。当我查看我的执行计划时，我的大部分处理都花在了 Table Spool 上。有没有什么好的技术可以改善这些类型的性能问题？与临时表相比，使用视图或 CTE 会给我带来什么好处吗？

我还注意到，当我将鼠标悬停在每个表假脱机上时，输出列表来自同一个临时表。

我正在尝试提高运行速度非常慢的查询的性能。经过实际执行计划后；我发现聚集索引搜索占用了 82%。有什么方法可以提高Index Seek的性能吗？

指数：

表（为简洁省略了一些列）：

我正在尝试加快我拥有的长时间运行的查询（运行大约需要 10 分钟......）。为了追踪查询的哪一部分花费我最多的时间，我在运行它时包含了实际执行计划，并发现一个占 55% 的特定部分（下面的屏幕截图）

替代文字 http://img109.imageshack.us/img109/9571/53218794.png

这对我来说似乎不太正确，所以我在这个麻烦部分之前和之后Print '1'添加了。Print '2'当我运行查询仅 17 秒然后取消它时，我假设的 1 和 2 打印输出意味着它在前 17 秒内通过了该部分。

替代文字 http://img297.imageshack.us/img297/4739/66797633.png

我在这里做错了什么还是我的执行计划误导了我？