UNION 子查询的奇怪行为，为什么？答案

【问题标题】：Odd Behavior of UNION Subquery, why?UNION 子查询的奇怪行为，为什么？
【发布时间】：2012-12-19 15:36:40
【问题描述】：

以下两个查询返回相同的信息；但是，第一个需要 1.1 秒完成，第二个需要 0.06 秒。

此表有 198,810 条记录，"Contacts"."ReqID" 已编入索引。

为什么我看到（看似）不太复杂的查询对性能造成如此大的影响？
为什么 UNION 子查询会加快处理速度？

*编辑*

我快速连续运行了这两个查询，但性能没有变化。

查询 1

SELECT
    "Contacts"."ContactID",
    "Contacts"."ReqID"
FROM
    "Contacts"
WHERE
    "Contacts"."ReqID" = 2426;

*编辑*

解释分析

Index Scan using "Contacts_ReqID_idx" on "Contacts"  (cost=0.00..30.08 rows=11 width=78) (actual time=0.076..0.115 rows=14 loops=1)
  Index Cond: ("ReqID" = 2426)
Total runtime: 0.159 ms

1.1 秒返回 14 条记录。

查询 2

SELECT
    "T1"."ContactID",
    "T1"."ReqID"
FROM
    (
        SELECT
            "Contacts"."ContactID",
            "Contacts"."ReqID"
        FROM
            "Contacts"
        WHERE
            "Contacts"."ReqID" = 2426
        UNION
        SELECT
            "Contacts"."ContactID",
            "Contacts"."ReqID"
        FROM
            "Contacts"
        WHERE
            "Contacts"."ReqID" = 2426
    ) AS "T1"
ORDER BY
    "ReqID"

*编辑*

解释分析

Sort (cost=61.74..61.80 rows=22 width=100) (actual time=0.313..0.329 rows=14 loops=1)
  Sort Key: "Contacts"."ReqID"
  Sort Method: quicksort  Memory: 26kB
  ->  HashAggregate  (cost=60.81..61.03 rows=22 width=78) (actual time=0.266..0.285 rows=14 loops=1)
        ->  Append  (cost=0.00..60.37 rows=22 width=78) (actual time=0.063..0.201 rows=28 loops=1)
              ->  Index Scan using "Contacts_ReqID_idx" on "Contacts"  (cost=0.00..30.08 rows=11 width=78) (actual time=0.059..0.106 rows=14 loops=1)
                Index Cond: ("ReqID" = 2426)
              ->  Index Scan using "Contacts_ReqID_idx" on "Contacts"  (cost=0.00..30.08 rows=11 width=78) (actual time=0.006..0.024 rows=14 loops=1)
                Index Cond: ("ReqID" = 2426)
Total runtime: 0.410 ms

0.06 秒返回 14 条记录。

【问题讨论】：

如果以相反的顺序运行“测试”会发生什么？
+ 在获取统计信息之前尝试多次运行它们（以启用缓存）。
是的，查询 1 会影响查询 2 的速度。通过从磁盘中拉入页面。另外：请将您的调整参数添加到问题中。（我怀疑你使用默认设置运行 postgres）
我不知道navicat是什么，但它确实会以某种方式影响你的结果。（也许它首先建立了一个连接？）消除中间人：从 psql 提示符下工作，或者使用 pgadmin3。
哇，PgAdmin 显示非常不同的数字，查询 1 为 5.500 毫秒，查询 2 为 7.118 毫秒。

标签： sql postgresql navicat

【解决方案1】：

事实证明，Navicat（我用来访问和管理我的数据库的软件）正在运行一些额外的代码，允许在运行简单的 SELECT * FROM [Table] 语句时就地编辑数据。以下是我从支持代表处收到的电子邮件。

尊敬的 [Navicat 用户]，

感谢您的电子邮件。请注意，为了得到列信息并允许之后更新数据，Navicat 将额外运行查询是简单的 SELECT 查询时的 SQL。使用 UNION，Navicat 不行允许用户更新查询结果中的任何数据。

...

此致
Mayho Ho
Navicat 支持中心

【讨论】：