标签: query-performance

我有一个基于 col1 int 分区的分区表。我还有一个覆盖索引，用于我尝试解决的查询。

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

以上是计划

任其发展，SQL Server 决定对整个表进行聚集索引扫描，这显然很慢。如果我强制索引（如上面的计划），查询会快速运行。

SQL Server 使用什么魔术逻辑来确定覆盖索引没有用？我不确定 top/orderby 和 rowgoal 是否与它有关。

我的表结构是

Create table object2(col1 int, col3 datetime, col4 int, col5, col6 etc) clusterd on col1

nonclustered non aligned index is on col3,col4 (col1 is clustered so its included in nonclust)

SELECT top(?) Object1.Column1
    FROM Object2 Object1 WITH (NOLOCK,index(Column2))
    WHERE  Object1.Column3 >= ?
    AND Object1.Column4 IN (?)
    ORDER BY Object1.Column1

编辑添加的回购

    CREATE PARTITION FUNCTION [PFtest](int) AS RANGE RIGHT FOR VALUES (100000, 200000, 300000, 400000, 500000, …

换句话说，我怎样才能摆脱下图中的sort操作符？

上图显示了以下2个select的执行计划：

                SELECT   TOP 1 so.OrgType, 
                              ch.Status, 
                              rcs.DBSstatusDescription, 
                              cid.ApplicationId
                   FROM   tbl_application_crb_initialData cid

                   INNER JOIN  tbl_season_organisationId so
                          ON   cid.OrganisationId = so.OrgId

                   LEFT JOIN  tbl_crbHistory ch  
                          ON  cid.ClientReference = ch.ClientReference

                   LEFT JOIN  ref_crbStatus rcs
                         ON   ch.Status = rcs.statusId    

                   ORDER BY  cid.DateAdded DESC, ch.DateAdded DESC

                SELECT   TOP 1 so.OrgType, 
                              ch.Status, 
                              rcs.DBSstatusDescription, 
                              cid.ApplicationId
                   FROM   tbl_application_crb_initialData cid

                   INNER JOIN  tbl_season_organisationId so
                          ON   cid.OrganisationId = so.OrgId

                   LEFT JOIN  tbl_crbHistory ch  
                          ON  cid.ClientReference = ch.ClientReference

                   LEFT JOIN  ref_crbStatus rcs
                         ON   ch.Status = rcs.statusId …

题

我有一个查询，它输出一个column，通过一系列CASE语句创建。这同样column被用作同一语句中CASE第二个逻辑的一部分。columnSELECT

如果我要构建一个CTE应用了内部逻辑的结构，那么当我必须将其用作以后的决定时，我可以参考内部逻辑。总的额外开销是多少？

据我了解，没有增加任何真正的开销。（下面是我使用的一些研究和一个简单的测试用例）。是否有文章讨论过这种情况或情况并非如此？

研究和简单的测试用例

我发现有几篇文章没有指出这个特定的问题，而是告诉我没有增加操作开销的方向。

• https://www.scarydba.com/2016/07/18/common-table-expression-just-a-name/
• https://www.sqlshack.com/why-is-my-cte-so-slow/

我针对我们现有的一个数据库编写了一个小查询来测试这个理论。结果和执行时间相同，Thestatistics和Query Execution Plan.

Code，Execution Plan而Statistics对于非CTE版本：

SELECT PC.CompanyID,
PC.ClientID,
PC.ProgramID,
PC.PatientID,
PC.CaseID,
CASE
    WHEN PFH.FulFilHdrCreateDateTime IS NULL
        THEN PC.CaseCreateDateTime
    ELSE
        PFH.FulFilHdrCreateDateTime
    END AS [ImportantDate],
DATEDIFF(Day, CASE WHEN PFH.FulFilHdrCreateDateTime IS NULL THEN PC.CaseCreateDateTime ELSE PFH.FulFilHdrCreateDateTime END, GETDATE())
FROM PATIENTCASES PC
    LEFT OUTER JOIN PATFULFILLMENTHEADER PFH
        ON PFH.CompanyID = PC.CompanyID
        AND …

我有一个疑问：

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 中有 …

我们有一些非常慢的复杂查询。我设法将查询简化为简单的复制。看来，组合greatest和log是原因，但我不明白为什么。

这是运行查询的完整sql-fiddle 示例- 您也可以View the execution Plans查询（按 sql-fiddle 页面上查询结果底部的链接）

所以这里是慢查询：

select count(value)
from (
         SELECT  log(greatest(1e-9, x)) as value
         from (select generate_series(1, 20000, 1) as x) as d
     ) t;

我们只是生成一系列 20k 数字并使用log(greatest()). 此查询大约需要1.5秒。

我认为计算日志可能需要很长时间，但以下查询也很快（~5ms）：

select count(value)
from (
         SELECT  log(x) as value
         from (select generate_series(1, 20000, 1) as x) as d
     ) t;

正如测试我交换greatest和log-这也是快速（大约为5ms）：

select count(value)
from …

我有一个查询，它与 8 的 MAXDOP 并行运行。当我查看时，sp_who2我看到相同的会话 ID 使用不同的连接 ID 重复多次（> 8）。

我使用了下面的查询，看到等待类型仍然是 CXCONSUMER 等待类型。但我看到 130 个不同的 exec_context id。

SELECT 
    dot.session_id,
    dot.exec_context_id,
    dot.task_state,
    dowt.wait_type,
    dowt.wait_duration_ms,
    dowt.blocking_session_id,
    dowt.resource_description
FROM sys.dm_os_tasks dot
    LEFT JOIN sys.dm_os_waiting_tasks dowt
        ON  dowt.exec_context_id = dot.exec_context_id
            AND dowt.session_id = dot.session_id
WHERE dot.session_id = 96
ORDER BY exec_context_id;

如果查询并行运行，当我将负载分配到不同的工作线程时，它是否具有不同的 spid。？

看了肯德拉·利特尔 (Kendra Little) 的文章。非常有帮助的一个。

我使用查询来查看并行处理查询中使用的不同调度程序。

我看到多次使用相同的shcheduler_id/worker地址。这正常吗？

我的 MAXDOP 也是 4，但我看到 5 个不同的 scheduler_ids，这很奇怪。

我有一个varchar(200)列，其中包含诸如，

ABC123124_A12312 ABC123_A1212 ABC123124_B12312 AC123124_AD12312 A12312_123 等等..

我想用一个数字替换一个数字序列，*以便我可以对表格中的不同非数字模式进行分组。

这个集合的结果是 ABC*_A* ABC*_B* AC*_AD* A*_*

我在下面编写了以下原始查询，它可以正常工作，但是在一张大表上运行需要很长时间。

我需要帮助重写或编辑它以提高它的性能。SQL Server 2014

-- 1. replace all numeric characters with '*'
-- 2. replace multiple consecutive '*' with just a single '*'
SELECT REPLACE
        (REPLACE
             (REPLACE
                  (REPLACE
                       (REPLACE
                            (REPLACE
                                 (REPLACE
                                      (REPLACE
                                           (REPLACE
                                                (REPLACE
                                                     (REPLACE
                                                          (REPLACE
                                                               (REPLACE(SampleID, '0', '*'),
                                                                '1', '*'),
                                                           '2', '*'),
                                                      '3', '*'),
                                                 '4', '*'),
                                            '5', '*'),
                                       '6', '*'),
                                  '7', '*'),
                             '8', '*'),
                        '9', '*')
                  , '*', '~*') -- replace each …

我有一个包含 17,093,139 行的大堆表。该表是数据库中使用最频繁的表。由于这是一个堆表，因此该表中只有非聚集索引。我定期重建/重组这个表上的碎片索引。

现在我们经常面临这个问题：访问此表的大量查询突然开始比平时花费更长的时间。当我检查时，我观察到查询的执行计划已更改。

我创建并删除了一个随机的非聚集索引，这解决了这个问题。

我不明白的是，是什么导致这些突然突然变慢的原因是什么，创建和删除索引在后台对表做了什么来修复它，而索引重建作业没有做？

我需要找出究竟是什么触发了这些减速，以便找到一个永久的解决方案，因为我不能只是每次都继续创建和删除索引来解决这个问题。

这里的任何帮助将不胜感激。

我有一个 Postgresql 11 数据库。假设我有一张桌子，叫做houses。它应该有数十万条记录。

CREATE TABLE houses (
  pkid serial primary key,
  address varchar(255) NOT NULL,
  rent float NOT NULL
);

现在，我的房子有我想在数据库中注册的功能。由于可能的功能列表会很长（几十个）并且会随着时间的推移而演变，因为我不想在表屋中添加一长串列并使用“ALTER TABLE”不断更改表，我想到了这些功能有一个单独的表格：

CREATE TABLE house_features (
   pkid serial primary key,
   house_pkid integer NOT NULL,
   feature_name varchar(255) NOT NULL,
   feature_value varchar(255)
);
CREATE INDEX ON house_features (feature_name, feature_value);
ALTER TABLE house_features ADD CONSTRAINT features_fk FOREIGN KEY (house_pkid) REFERENCES houses (pkid) ON DELETE CASCADE;

平均而言，每个房屋记录在house_features表中将有 10-20 条记录。

到目前为止，这似乎是一个简单高效的模型：我可以添加尽可能多的不同功能，控制上层（应用层和/或 GUI）中feature_name和feature_value的可能值。每次应用程序发展时我都不必更改数据库，我需要一种新的功能。 …

对于我们的一个数据库，如下所示的查询非常慢。

由于安全原因，我无法分享实际的查询或计划，但只是想知道如何编写查询如下

SELECT [Id]
      ,[AboutMe]
      ,[Age]
      ,[CreationDate]
      ,[DisplayName]
      ,[DownVotes]
      ,[EmailHash]
      ,[LastAccessDate]
      ,[Location]
      ,[Reputation]
      ,[UpVotes]
      ,[Views]
      ,[WebsiteUrl]
      ,[AccountId]
  FROM [StackOverflow2010].[dbo].[Users]
  WHERE DisplayName IN (

 SELECT DisplayName from dbo.Users
 WHERE CAST(LastAccessDate AS DATE) = CAST ('20160814' AS DATE)
 AND CreationDate>= DATEADD (DAY, -30,LastAccessDate)
 AND CreationDate<= LastAccessDate)

在 stackoverflow 数据库中，这不会返回任何行，但对于我们现有的 6 TBS 数据库，它真的很慢。

CreationDate和LastAccessdate列都是日期时间 (10)

和 DisplayName是VARCHAR（50）

如果以上可以重写，请建议我如何提高性能