标签: execution-plan

如何在消息窗格上打印每个查询的执行时间？例如，Select * from tbl1运行 10 分钟，然后Select * from tbl2运行 ​​15 分钟，依此类推。

Select * from tbl1
Go
Select * from tbl2
Go
Select * from tbl3
Go

我有两个结果集：

rs1:

     id       name
   serial     text
________________
     1        Nick
....................
  1233112     Pete

rs2:

     id       name
   serial     text
________________
  123121      Mike
....................
 221233112   Junior

如果我们写一个查询：

SELECT *
FROM
(

    SELECT *
    FROM rs1

    UNION ALL

    SELECT *
    FROM rs2

) as rs
OFFSET 100000 LIMIT 10;

查询结果是如何计算的？将使用什么算法？

我相信服务器执行惰性评估是指不加载整个联合，对其进行迭代，然后返回所需的结果。

如果您描述了其他 SQL 服务器中使用的算法作为补充，我将很高兴。

UPD：我对数据库内部结构很陌生，不知道是否可以向 sql-server 本身询问查询的执行计划。

这是一个查询计划：

"Limit  (cost=77.11..77.88 rows=10 width=522)"
"  ->  Append  (cost=0.00..140.18 rows=1818 width=522)"
"        ->  Seq Scan on tbl  (cost=0.00..70.09 rows=909 width=522)"
"        ->  Seq Scan on …

考虑这两个查询：

SELECT
    t1.id, *
FROM
    t1
INNER JOIN
    t2 ON t1.id = t2.id
    where t1.id > -9223372036513411363;

和：

SELECT
    t1.id, *
FROM
    t1
INNER JOIN
    t2 ON t1.id = t2.id
    where t1.id > -9223372036513411363 and t2.id > -9223372036513411363;

注意：不是-9223372036513411363表中的最小值，并且条件将结果（从总行数 3.5 亿行）减少到 1700 万行。

就我个人而言，我希望 PostgreSQL 能够为这两个查询提供相同的计划，因为t1.id = t2.id自动意味着第二个条件。但不幸的是，PostgreSQL 正在创建两个不同的计划，第二个计划要好得多：

• 第一个查询： http: //explain.depesz.com/s/uauk
• 第二次查询：链接： http: //explain.depesz.com/s/uQd
• 对第二个查询进行解释分析：http://explain.depesz.com/s/Snkx （第二个查询在 215 秒内完成，而第一个查询在 1000 秒后才完成，直到我终止它）。

我非常喜欢第一个查询，因为我想从连接创建一个视图，并将 where 条件放在视图上的查询上，我在其中看到单个 id 列（我使用连接，USING因此单个 id 列在视图中可见） 。另外，我将连接两个以上的表，并且我不希望为每个连接添加这样的条件。

这种行为有什么原因吗？或者这是一个错误？有什么解决方法吗？

• 替换ON …

（从我的帖子复制到 postgresql 邮件列表https://www.postgresql.org/message-id/CADBa3wZpuYXwdry2g68NxYmAXOPvx0DLvdAU4kdo2GoPtxKu+Q@mail.gmail.com。不幸的是，我需要至少 10 声誉才能发布 2 个以上链接，因此请参考到原始帖子以获取更多链接）

问题的基本摘要：在 12GB 表中的一列上使用行级安全过滤器会导致位图堆扫描缓慢，而不是作为表所有者执行的查询所使用的快速索引扫描（没有任何行级安全过滤器）。安全）。手动写入过滤条件也可以实现快速索引扫描。比照。https://gist.github.com/charles-cooper/abccf41ce5a1175635414321622fba57查看本文中的所有代码。

表说明如下：

 Table "data.sm2dvmoam"
  Column   |            Type             | Modifiers | Storage | Stats target | Description 
-----------+-----------------------------+-----------+---------+--------------+-------------
 item      | smallint                    | not null  | plain   |              | 
 secid     | integer                     | not null  | plain   |              | 
 startdate | timestamp without time zone | not null  | plain   |              | 
 enddate   | timestamp without time zone |           | plain   |              | 
 value_    | real                        |           | plain …

清除 SQL Server 上的计划缓存后，如何重新生成存储过程的执行计划而不执行存储过程本身？

当我今天早上更新统计数据时，我的一个存储过程运行得非常缓慢。根据一些谷歌，我发现清除计划缓存可以解决这个问题 - 确实如此。但是，如果我必须再次执行此操作，我希望避免在用户等待响应时重新生成计划对性能造成影响。

SQL Server 的版本/版本是 2016 Enterprise。

我们的 ERP 系统存在一些性能问题。06:00 左右，问题开始出现。长话短说; 我的一位同事执行了DBCC FREEPROCCACHE（我知道这不是首选操作，但这不是重点）。之后，他重新启动了整个 ERP 应用程序，而不是数据库引擎。这似乎没有帮助。我查看了查询存储，发现查询计划在 06:05 左右发生了更改。我尝试强制执行旧计划，性能问题就消失了。

我比较了 2 个计划 XML，发现两者都基于相同的统计数据（更新日期完全相同）。索引上的更改数量不同，但这不会触发更新统计信息，因为否则新的查询计划将为所使用的统计信息提供新的日期。我检查了涉及的表的所有统计信息，但自上次维护工作以来，它们没有更新。最后一次维护作业在本周末运行，这也是两个查询计划中使用的统计信息的更新日期。

该查询是参数化查询，所以我有点不清楚为什么查询计划突然改变。我认为恰恰相反，查询突然运行缓慢，因为相同的计划用于不同的参数。这里的情况似乎并非如此，因为我强制使用旧的查询计划。

该查询来自一些检索订单的定制工作。现在，我怀疑有人发出了参数化查询，该查询会返回一个非常大的数据集，从而减慢 ERP 系统的速度。然后，我的同事运行了一个DBCC FREEPROCCACHE命令，根据本周末的新统计数据触发了查询计划的重新编译。当前查询继续运行，他决定重新启动 ERP 应用程序。现在，使用新的查询计划，所有新查询都会变慢，直到我强制使用旧的查询计划。

这能是解释吗？我有点怀疑，因为当统计数据发生变化时，SQL Server会触发重新编译，所以计划应该在索引维护作业之后已经重新编译。

我想我在这里遗漏了一些东西，但我不确定是什么。它是SQL Server 2016 Standard，是ERP系统的专用服务器。

编辑 15-4-2020 12:17：既然我写了这个...我认为问题在于DBCC FREEPROCCACHE第一次执行有问题的参数化查询的参数使用了不同的参数，这导致 SQL Server 重新编译（坏）计划。或者我还缺少什么吗？

我这里有一个非常奇怪的问题。我们的搜索查询接收多个参数并通过不同表中的多个联接进行搜索。查询在我们运行的前几次运行良好，然后有时会严重减慢，例如：从 200 毫秒到 15000/20000 毫秒。在同一个查询上。

最初我认为这是后端 ORM 问题，但在彻底检查并打开慢速查询日志、打开 auto_explain 功能后，我意识到查询计划在几次调用后发生了变化。我们在后端放置一个循环，在同一线程上多次执行查询（用于测试），我发现几乎总是在执行 8 次后数据库开始记录慢速查询。最后结果是查询计划发生了变化。最重要的变化是（我认为）TimeSlots 表上的变化，从 seq 扫描到位图索引扫描，它估计的行数比表中的行数少得多。估计：566 实际：100 000 左右。

我之前尝试过的事情：

• 将硬件从 2 核 6GB 升级到 8 核 26GB 内存（100GB SSD）
• 禁用任何其他应用程序（从而停止任何其他负载）访问它。
• 在表上执行手动（也有自动运行的作业）VACUUM、ANALYZE、REINDEX。
• 设置各个列的统计信息，例如SlotDateTime（至10000）
• 创建不明确的统计数据。
• 增加了 work_mem、maintenance_work_mem、shared_buffers 大小。
• 将 seq_page_cost 减少到 1。

这是选择语句：

SELECT DISTINCT u."UserId"     AS                                     UserId,
                             cast(cuj.company_id as bigint) AS                                     CompanyId,
                         cast(ts.SlotsCount as bigint) as SlotsCount,
                         case when cuj.vip is null then false else cuj.vip end vip,
                         u.is_vip       as                                     userVip,

                         case
                             when ts2.EarliestDate isnull then '7777-12-01 21:00:00.000000'
                             else ts2.EarliestDate …

我喜欢在旅途中查找丢失的索引，查看执行计划！

如果我想改进当前正在运行的东西，它可能会给我一个进一步的指示。

为此，我使用以下查询：

SET NOCOUNT ON
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED


SELECT 
    er.session_id,
    er.blocking_session_id,
    er.start_time,
    er.status,
    dbName = DB_NAME(er.database_id),
    er.wait_type,
    er.wait_time,
    er.last_wait_type,
    er.granted_query_memory,
    er.reads,
    er.logical_reads,
    er.writes,
    er.row_count,
    er.total_elapsed_time,
    er.cpu_time,
    er.open_transaction_count,
    er.open_transaction_count,
    s.text,
    qp.query_plan,
    logDate = CONVERT(DATETIME,GETDATE()),
    logTime = CONVERT(DATETIME,GETDATE())
FROM sys.dm_exec_requests er 
CROSS APPLY sys.dm_exec_sql_text(er.sql_handle) s
CROSS APPLY sys.dm_exec_query_plan(er.plan_handle) qp
WHERE 
    CONVERT(VARCHAR(MAX), qp.query_plan) LIKE '%<missing%'

它通常工作正常；但是，我最近遇到了整理和 XML 的问题：

错误信息说：

SET NOCOUNT ON
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED


SELECT 
    er.session_id,
    er.blocking_session_id,
    er.start_time,
    er.status,
    dbName = DB_NAME(er.database_id),
    er.wait_type, …

我的应用程序中的查询之一是超时。使用 SQL Server 分析器，我能够获得准确的错误 SQL 代码。这是一个sp_executesql动态语句，在服务器上的 SSMS 中运行时间超过 2 分钟。相比之下，临时运行相同的 SQL - 在外面sp_executesql但仍然有参数 - 只需要 600 毫秒。

查看缓存的执行计划，这 2 个查询具有完全相同的查询哈希但不同的计划。我 DBCC FREEPROCCACHEd 准备好的（慢的）希望接下来的执行可以重用临时的快速查询的计划。但事实并非如此。运行 sp_executesql 查询总是重新弹出一个新的、缓慢的计划。

按照此处的指南，我研究了参数嗅探的可能性。才发现我的4个参数在两个执行计划中完全一样。

我还尝试OPTION (RECOMPILE)更新相关表的统计信息，但没有结果。

执行计划有 2 个非常相似的主要分支，除了较慢的一个在分支的连接处有嵌套循环，而快速的没有。较低的分支叶子是两个计划中的索引扫描，除了较慢的一个读取数百万行，而较快的一个读取数千行。

在较快的索引的使用上没有明显的区别。顶部分支的组织方式略有不同。

准备好的查询可以重用临时缓存的执行计划吗？是什么导致了如此巨大的性能差异？

我想共享我的屏幕并显示一个执行计划，但是当我将鼠标悬停在一个操作符上以及在工具提示中用我的鼠标指向什么时，它就会消失。当我将鼠标指向一些信息时，有没有办法保持打开状态？

谢谢