标签: execution-plan

这是来自 Postgres 9.6 的 EXPLAIN ANALYZE 的一部分：

->  Bitmap Heap Scan on cities  (cost=90.05..806.49 rows=265 width=4) (actual time=4.733..45.772 rows=17 loops=1)
       Recheck Cond: (regexp_replace(regexp_replace(replace(replace(replace(replace(lower(name), 'ä'::text, 'ae'::text), 'ö'::text, 'oe'::text), 'ü'::text, 'ue'::text), 'ß'::text, 'ss'::text), 'strasse\M'::text, 'strasse'::text, 'g'::text), '\W'::text, ''::text, 'g'::text) % 'coerde'::text)
      Rows Removed by Index Recheck: 567
      Heap Blocks: exact=497
      ->  Bitmap Index Scan on city_lookup_index  (cost=0.00..89.98 rows=265 width=0) (actual time=4.229..4.229 rows=584 loops=1)
             Index Cond: (regexp_replace(regexp_replace(replace(replace(replace(replace(lower(name), 'ä'::text, 'ae'::text), 'ö'::text, 'oe'::text), 'ü'::text, 'ue'::text), 'ß'::text, 'ss'::text), 'strasse\M'::text, 'strasse'::text, 'g'::text), '\W'::text, ''::text, 'g'::text) % 'coerde'::text) …

在这个答案中， Erwin 将IMMUTABLE函数分解为可以内联的函数和不能内联的函数。他有一个例子to_char()，表明IMMUTABLE函数 overto_char()实际上会更慢。

不过这很有趣，因为我什至不知道to_char()不是IMMUTABLE。此外，我不知道这IMMUTABLE会让任何事情变得更慢。我现在的问题是，如何确定标记为IMMUTABLE内联的函数是否被内联？

我在这里发生了哈希匹配溢出。我已经用 FULLSCAN 更新了涉及的表的统计信息，所以不是这样。任何指针都非常感谢。

https://www.brentozar.com/pastetheplan/?id=Bkq1VjySm

我使用的是 SQL 2017 Enterprise，内存为 64GB。

我有一些参数化的查询，但它们每次仍在创建一个新的执行计划。我正在使用 SQL Server 2016。

查询如下：

(@P1 varchar(1043),@P2 varchar(6))
UPDATE table 
SET FILEDATA=@P1 
WHERE FILEID=@P2

这个查询没有使用缓存中已经生成的执行计划，而是每次都创建一个新计划。

我创建了一个示例表，如下所示

CREATE TABLE [dbo].[StatisticsDemo](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [Name] [nvarchar](50) NULL
   ) ON [PRIMARY]

然后我插入以下数据如下：

SELECT NAME,COUNT(*) AS COUNT 
FROM StatisticsDemo 
GROUP BY NAME

NAME    COUNT
-------------
AABBCC  59999
XXYYZZ  1

然后我在下面创建了非聚集索引：

CREATE NONCLUSTERED INDEX [NCI_STATISTICSDEMO_NAME] ON [dbo].[StatisticsDemo]
(
    [Name] ASC
)

现在我运行了以下查询：

SELECT NAME FROM [dbo].[StatisticsDemo] 
WHERE NAME = 'AABBCC'

正如预期的那样，它返回 59999 行，但它正在对非聚集索引进行索引查找。但据我所知，它应该进行索引扫描，因为 99.99% 的数据满足选择查询中提到的过滤条件。

有人能告诉我为什么它在做索引搜索而不是索引扫描吗？

整个活动的目的是证明（正如我将要介绍的统计数据）SQL Server 在准备执行计划之前查看统计数据以识别符合查询过滤条件的记录数，并基于百分比记录匹配表中的总记录，它将决定执行扫描或搜索。如果匹配记录的百分比大约等于表中的记录总数，则应执行 SCAN。但这并没有发生。当我使用 AdventureWorks2016 数据库并运行以下查询时也是如此：

select * from [Sales].[SalesOrderHeader] WHERE SalesOrderID >= 43659 AND 
SalesOrderID <= 73659

上面的查询返回 31465 条记录中的 30001 …

我有一个疑问：

SELECT  Id, 
        ColumnA,
        ColumnB
FROM    MyTable
WHERE   ColumnA = @varA OR
        ColumnB = @varB  

该表定义为

CREATE TABLE MyTable
(
    Id INT IDENTITY(-2147483648,1) PRIMARY KEY,
    ColumnA VARCHAR(22)
    ColumnB VARCAHR(22)
)

并且表上有一个非聚集索引

CREATE INDEX IX_MyIndex ON MyTable
(
    ColumnA
)

当我使用以下参数运行查询时：

DECLARE @varA nvarchar(4000) = ''
DECLARE @varB  nvarchar(8) = '10140730'

执行计划显示索引搜索IX_MyIndex，但它显示读取的行数为 1700 万行，但实际行数为 0（MyTable.ColumnA 中有 0 行，值为 ''）如果我转动，SET STATISTICS IO ON我可以看到完整的表正在阅读

这是有道理的：“这是一个“糟糕的”索引搜索部分中的这篇文章

但是，当我使用参数运行相同的查询时：

DECLARE @varA nvarchar(8) = 'a'
DECLARE @varB  nvarchar(8) = '10140730'

搜索运算符没有“读取的行数”属性（MyTable.ColumnA 中有 …

这是计划：https : //www.brentozar.com/pastetheplan/?id=rkM8d7ONS

我最感兴趣的是如何摆脱懒惰的线轴？

这是查询：

SELECT DISTINCT 
        SM.Security_ID 'Security_ID',  
        Leg.Leg_Type 'Leg_Type', 
        Leg.Leg_Side 'Leg_Side',
        Ct.Security_Type AS 'Swap_Type',
        Leg.CDX_Indicator AS 'CDS_CDX_Flag',
        SM.Currency AS 'Notional_Currency',
        Ct.Cross_Currency_Flag AS 'Cross_Currency_Flag',
        Ct.Custom_Overrides AS 'Special_Instructions',
        Leg.Protection_Indicator AS 'Buy_Sell_Protection',
        Leg.Commission_Direction AS 'Commission_Direction',
        Leg.Dividend_Payment_Indicator AS 'Undl_Asset_Dividend_Flag',
        SM.Issue_Date AS 'Effective_Date',
        SM.Maturity_Date AS 'Maturity_Date',
        Leg.Settlement_Frequency 'Settlement_Frequency',
        Leg.Reset_Frequency 'Reset_Frequency',
        Leg.Roll_Day AS 'Roll_Day',
        Leg.Reset_Business_Day_Convention AS 'Reset_Business_Day_Convn',
        Leg.Settlement_Business_Day_Convention AS 'Settlement_Business_Day_Convn',
        Leg.First_Payment_Date AS 'First_Period_End_Date',
        Leg.Day_Count AS 'Day_Count_Basis',
        Leg.Interest_Rate AS 'Interest_Rate',
        Leg.Spread AS 'Spread',
        Leg.CDX_Attachment AS 'CDX_Attachment',  
        Leg.CDX_Detachment AS 'CDX_Detachment',  
        Leg.Factor AS 'Factor',
        Leg.Commission AS …

我正在对我公司的一些 SQL 进行一些性能基准测试，将 PG10 与 PG12 进行比较。我们在代码中使用了很多CTE，而 PG12 并没有对 CTE 进行原生优化，因此 PG10 和 PG12 之间的性能是相同的。

我的下一个实验是将NOT MATERIALIZED指令添加到 CTE，结果令人震惊：它大大缩短了查询时间（在某些情况下将它们减半）。

我在这里读到这MATERIALIZED是 PG12 之前的默认功能。该功能会将 CTE 的所有内容写入一个临时位置。

所以我的问题主要是NOT MATERIALIZED：

1. 与 相比，该NOT MATERIALIZED功能对幕后的数据MATERIALIZED有何作用？
2. NOT MATERIALIZED在重构我们的代码库之前，我应该注意哪些副作用？

将应用程序及其数据库从经典 PostgreSQL 数据库迁移到 Amazon Aurora RDS PostgreSQL 数据库（均使用 9.6 版本）后，我们发现特定查询在 Aurora 上的运行速度要慢得多——大约慢 10 倍在 PostgreSQL 上。

两个数据库都具有相同的配置，无论是硬件还是 pg_conf。

查询本身相当简单。它是从我们用 Java 编写的后端生成的，并使用 jOOQ 编写查询：

with "all_acp_ids"("acp_id") as (
    select acp_id from temp_table_de3398bacb6c4e8ca8b37be227eac089
) 
select distinct "public"."f1_folio_milestones"."acp_id", 
    coalesce("public"."sa_milestone_overrides"."team", 
    "public"."f1_folio_milestones"."team_responsible") 
from "public"."f1_folio_milestones" 
left outer join 
    "public"."sa_milestone_overrides" on (
        "public"."f1_folio_milestones"."milestone" = "public"."sa_milestone_overrides"."milestone" 
        and "public"."f1_folio_milestones"."view" = "public"."sa_milestone_overrides"."view" 
        and "public"."f1_folio_milestones"."acp_id" = "public"."sa_milestone_overrides"."acp_id"
)
where "public"."f1_folio_milestones"."acp_id" in (
    select "all_acp_ids"."acp_id" from "all_acp_ids"
)

用temp_table_de3398bacb6c4e8ca8b37be227eac089是单个列的表，f1_folio_milestones（17万个条目）和sa_milestone_overrides（100万左右的条目）是具有在所有用于列索引类似设计的表LEFT OUTER JOIN。

temp_table_de3398bacb6c4e8ca8b37be227eac089 最多可以包含 5000 …

我正在尝试优化查询以更快地运行。查询如下：

SELECT grp_fk_obj_id, grp_name
FROM tbl_groups as g1
         CROSS APPLY (SELECT TOP 1 grp_id as gid
                      FROM tbl_groups as g2
                      WHERE g1.grp_fk_obj_id = g2.grp_fk_obj_id
                      ORDER BY g2.date_from DESC, ISNULL(date_to, '4000-01-01') DESC) as a
WHERE g1.grp_id = gid

grp_id 是主键。grp_fk_obj_id 是另一个对象的外键。这两列都有索引（我猜它是默认的）。

完成大约需要半秒钟，但我需要它来加快工作速度。我查看了执行计划，它显示“Top N 排序”的成本超过 90%。另外，我注意到，如果我删除了交叉应用中的 where 子句，那么它的运行速度至少要快 5 倍，但我需要以一种或另一种方式使用 where 子句。

您是否认为有可能提高此查询的性能？

编辑：表创建 DDL：

create table tbl_groups
(
    grp_id        bigint identity
        constraint PK_tbl_groups
            primary key,
    grp_fk_obj_id bigint      not null
        constraint FK_grp_fk_obj_id
            references tbl_other,
    grp_name      varchar(30) not null,
    date_from     date        not null, …