标签: query-performance

我正在尝试优化以下查询（这是我能想到的最简化的版本）：

SELECT tr.Id, StatusDate
FROM (
    SELECT tr.Id, tr.StatusDate
    FROM mon.ArchivedTaskResults_201504 as tr WITH (NOLOCK)
    INNER JOIN mon.ViewDevicesWithGroups dev WITH (NOLOCK) ON tr.DeviceId = dev.Id
    WHERE tr.ClientId = 4 AND dev.Deleted = 0
) AS tr        
ORDER BY StatusDate DESC
OFFSET 1000000 rows
FETCH NEXT 25 ROWS ONLY

问题是，查询性能与 OFFSET 成正比 - 对于 offset=0 查询在 0.0 秒内执行，但对于 offset=1000000 执行时间约为 23 秒（如果偏移量更大，则可能需要几分钟）。

我几乎可以肯定我的问题可以通过 ArchivedTaskResults 表上的适当聚集索引来解决，但是在尝试了几个小时之后我仍然没有找到好的索引。

ArchivedTaskResults 表真的很大，大约有 50000000 行（50 M）

附加信息：

如果有人能解决我上面描述的问题，我会非常高兴，但说实话，我的真实查询更加奇怪（免责声明：我不是设计这个数据库的人）：

SELECT tr.Id, StatusDate
FROM (
    (
        SELECT tr.Id, StatusDate …

一些 RDBMS 似乎允许没有 FROM 子句的查询，例如：

postgres=# SELECT 'foo' bar;
???????
? bar ?
???????
? foo ?
???????

但是对于那些允许它的人，为什么SELECT count(*)不返回 0？

postgres=# SELECT count(*);
?????????
? count ?
?????????
?     1 ?
?????????

我有一个表，其中有一个 jsonb 列，其中包含一个对象数组。

每一行看起来都是这样。

[{grade: 'A', subject: 'MATH'}, {grade: 'B', subject: 'PHY'}...]

现在通过这篇文章查询它/sf/answers/2141445351/。

问题来了，完成查询所有具有gradeIN (A, B, C) 的学生的计数至少需要 2.4 秒。

我想得到一些关于索引的帮助，因为我尝试过的索引没有做任何事情。

DROP INDEX idx_subjects_subject;
DROP INDEX idx_subjects_grade;
CREATE INDEX idx_subjects_subject ON results USING GIN((subjects-> 'subject'));
CREATE INDEX idx_subjects_grade ON results USING GIN((subjects-> 'grade'));

还做了（单独）：

DROP INDEX idx_subjects_standard;
CREATE INDEX idx_subjects_standard ON results USING GIN(subjects);

我是这样问他们的。

SELECT COUNT(*)
FROM results
WHERE EXISTS 
    (
        SELECT 1 
        FROM jsonb_array_elements(subjects) AS j(data) 
        WHERE (data #>> '{subject}') LIKE '%MATH%' 
        AND 
        (data …

在我的查询中，我不确定如何解决某些问题。

一、定义：

快递服务表。有一个记录。

CREATE TABLE [dbo].[CS](
    [ServiceID] [int] IDENTITY(1,1) NOT NULL,
    [CSID] [nvarchar](6) NULL,
    [CSDescription] [varchar](50) NULL,
    [OperatingDays] [int] NULL,
    [DefaultService] [bit] NULL,
 CONSTRAINT [CourierServices_PK] PRIMARY KEY CLUSTERED 
(
    [ServiceID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,
       ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90
) ON [PRIMARY]
) ON [PRIMARY]

GO
SET IDENTITY_INSERT [dbo].[CS] ON 

INSERT [dbo].[CS] ([ServiceID], [CSID], [OperatingDays], [DefaultService])
           VALUES (1, N'RM48', 2, 1)
SET IDENTITY_INSERT [dbo].[CS] OFF
SET ANSI_PADDING ON

GO …

我有一个要加速的查询：

SELECT 
  sum(case when FlagDTD = 1 then Success else 0 end)   as SuccessDTD
, sum(case when FlagDTD = 1 then [Error] else 0 end)   as ErrorDTD
, round(sum(case when FlagDTD = 1 then Success else 0 end) * 100.0 / sum(FlagDTD),2) 
    as RateDTD
, sum(case when FlagYTD = 1 then Success else 0 end)   as SuccessYTD
, sum(case when FlagYTD = 1 then [Error] else 0 end)   as ErrorYTD
, round(sum(case when FlagYTD = 1 then Success else 0 …

我正在尝试为 1 亿行表中的 XML 列确定最有效的选择性 XML 索引。我的问题类似于：

用于选择性 Xml 索引的 Sql Server 2012 扩展事件未显示结果

但是答案中指定的选择性索引的具体好处没有详细讨论。

以下是查询的简化版本：

;WITH CTE AS
( SELECT 1 AS ID,
              CONVERT(XML, '<Root>
                              <ParentTag ParentTagID="Sample Text">
                                <ChildTag1>5</ChildTag1>
                                <ChildTag1>6</ChildTag1>
                                <ChildTag1>7</ChildTag1>
                                <ChildTag2>8</ChildTag2>
                                <ChildTag2>9</ChildTag2>
                                <ChildTag2>10</ChildTag2>
                                <OtherTag>LargeIrrelevantData</OtherTag>
                              </ParentTag>
                            </Root>'
                      ) AS SampleXML
)
SELECT * INTO dbo.CTE FROM CTE

SELECT ID,
       Root.ParentTag.value('@ParentTagID','NVARCHAR(MAX)') AS ParentTagID,
       RootParentTag1.ChildTag1.value('(text())[1]', 'NVARCHAR(MAX)') AS ChildTag1,
       NULL
FROM CTE
OUTER APPLY CTE.SampleXML.nodes('/Root/ParentTag') as Root(ParentTag)
OUTER APPLY Root.ParentTag.nodes('ChildTag1') as RootParentTag1(ChildTag1)
UNION
SELECT ID,
       Root.ParentTag.value('@ParentTagID','NVARCHAR(MAX)') AS ParentTagID,
       NULL,
       RootParentTag2.ChildTag2.value('(text())[1]', 'NVARCHAR(MAX)') AS …

我导入了ip2location_db11 lite 数据库的副本，其中包含 3,319,097 行，并且我希望优化数字范围查询，其中低值和高值位于表 ( ip_from, ip_to) 的不同列中。

导入数据库：

CREATE TABLE ip2location_db11
(
  ip_from bigint NOT NULL, -- First IP address in netblock.
  ip_to bigint NOT NULL, -- Last IP address in netblock.
  country_code character(2) NOT NULL, -- Two-character country code based on ISO 3166.
  country_name character varying(64) NOT NULL, -- Country name based on ISO 3166.
  region_name character varying(128) NOT NULL, -- Region or state name.
  city_name character varying(128) NOT NULL, -- City name. …

我有一个包含约 10 亿条时间戳记录的表，每条记录都包含一个会话表的 FK（每天一个会话和每天 3-500,000 条记录），因此查找给定日期的记录只是一个整数连接。

我正在尝试分析此表中的数据（数据按会话分组），当使用客户端计算机上的 C# 控制台应用程序时，我可以在 70 分钟内运行完整的分析（每条记录）。当我尝试直接在 TSQL 中运行类似的分析时，需要 12 多个小时。我预计会有一些惩罚，因为 TSQL 查询使用标量函数和自定义聚合 (clr)。

我的问题：在 C# 中，我了解如何最大化和调整并发性，因此 70 分钟是一个调整过的数字。是否可以直接在 SQL 中调整最大并发的查询，还是最好留给 C# api？（我也可以在 R、数据库或外部完成这项工作，但 .Net 并发 API 给我留下了优越的印象。）

询问：

SELECT TypeNumber, SessionId, dbo.udf_SessionName([timestamp]) SessionName, 
CAST(max(price)-min(price) AS REAL) as Variance, sum(EventNumber) as Volume, 
dbo.Direction(price,[timestamp]) as MoveDirection
INTO temp.AnalysisResults
FROM MyTable
WHERE ISNULL(price,0)<>0
GROUP BY TypeNumber, SessionId, dbo.udf_SessionName([timestamp])

杂项

• 由于插入，为此查询启用了批量记录
• 此查询中未使用主键（它是跨三个字段的复合键，此处不需要。但是，查询计划显示正在扫描此索引，而不是我在下面提到的索引（该计划最初推荐） ）。
• 行级压缩已启用
• 数据跨越五年，每个月有一个只读文件组（按月分区）；所有文件组都驻留在同一个 SSD 上（不太好，我知道）
• 索引：非聚集在 SessionId asc 上，包括 TypeNumber、Timestamp、Price
• 4 个 CPU 内核可用
• 标量函数获取每个时间戳，使用 AT …

在我的应用程序中，我有一个在“文件”表中执行搜索的查询。

该表files按f.created（参见表定义）进行分区，并为客户端 19 ( f.cid = 19)提供约 1 亿行。

我正在使用我上一个问题的答案中的这个查询， SQL Server 的慢顺序：

WITH PartitionNumbers AS
(
    -- Each partition of the table
    SELECT P.partition_number
    FROM sys.partitions AS P
    WHERE P.[object_id] = OBJECT_ID(N'dbo.files', N'U')
    AND P.index_id = 1
)
SELECT
    FF.id,
    FF.[name],
    FF.[year],
    FF.cid,
    FF.created,
    vnVE0.keywordValueCol0_numeric
FROM PartitionNumbers AS PN
CROSS APPLY
(
    SELECT
        F100.*
    FROM 
    (
        -- 50 rows in order for year 2013
        SELECT
            F.id,
            F.[name],
            F.[year],
            F.cid,
            F.created
        FROM dbo.files …

我们有一些顾问致力于扩展内部数据仓库。我正在做代码审查并在所有加载过程中遇到这种模式：

    MERGE [EDHub].[Customer].[Class] AS TARGET
    USING (
        SELECT <columns>
        FROM [dbo].[vw_CustomerClass]
            WHERE JHAPostingDate = @PostingDate   
        ) AS SOURCE
        ON  TARGET.BankId = SOURCE.BankId       -- This join is on the business keys
            AND TARGET.Code = SOURCE.Code
    WHEN NOT MATCHED BY TARGET  
        THEN
            <INSERT Statement>
    WHEN MATCHED
        AND TARGET.IsLatest = 1
        AND EXISTS (
            SELECT SOURCE.[HASH]   
            EXCEPT          
            SELECT TARGET.[Hash]
            )
        THEN 
            <UPDATE Statement>

要点是，如果我们有一个新的业务键，则插入，但如果业务键存在并且属性的散列与我们的当前行不匹配，则更新旧行并插入一个新行（稍后在代码中）。一切正常，但是当我看到这段代码时我暂停了

AND EXISTS (
            SELECT SOURCE.[HASH]   
            EXCEPT          
            SELECT TARGET.[Hash]
            )

与 SOURCE.[HASH] <> TARGET.[Hash] 相比，它似乎过于复杂。EXCEPT 将进行准确的 NULL 比较，但在我们的情况下，哈希值永远不会为 NULL（或者我们有更大的问题）。我希望我们的代码易于阅读，这样当有人必须维护它时，它不会混淆。我向我们的顾问询问了它，他们推测它可能会因为集合操作而更快，但我决定编写一个简单的测试（下面的测试代码）。

我注意到的第一件事是 …