标签: query-performance

我正在一些大表中运行查询，尽管它运行良好，即使是大量数据也很困难，但我想了解它的哪一部分对执行有影响。不幸的是，我不太擅长解释计划，所以我寻求帮助。

以下是有关这些表的一些数据：

• history_state_table 7.424.65行（其中只有13.412被后留下的t1.alarm_type = 'AT1'）
• costumer_price_history 448.284.169行
• cycle_table 215行

这将是查询（不要介意逻辑，仅供参考）：

SELECT t1.id_alarm, t2.load_id, t2.reference_date
  FROM history_state_table t1,
       (SELECT   op_code, contract_num,
                 COUNT (DISTINCT id_ponto) AS num_pontos,
                 COUNT
                    (DISTINCT CASE
                        WHEN vlr > 0
                           THEN id_ponto
                        ELSE NULL
                     END
                    ) AS bigger_than_zero,
                 MAX (load_id) AS load_id,
                 MAX (reference_date) AS reference_date
            FROM costumer_price_history
           WHERE load_id IN
                            (42232, 42234, 42236, 42238, 42240, 42242, 42244) /* arbitrary IDs depending on execution*/
             AND sistema = 'F1'          /* Hardcoded …

我是 ac# 开发人员，但是我对 SQL 很有经验。我在优化查询方面有一些经验，但我遇到了一个让我难倒的经验。

查询大约需要 3 分钟才能运行大约 20,000 行。行立即开始流式传输，但在 3 分钟内，SQL 服务器 cpu 固定在 100%。

在这种特殊情况下，我的查询执行得很好，直到客户要求我用 20k 行测试它们。这 20k 行（客户）分布在 20 个从业者中（所以每个人大约 1000 个）

这是我的相关表的数据库架构：

该查询使用递归 CTE 来收集给定源从业者的（n 级）客户端树。然后它连接到一些 FK 类型的表以收集额外的信息。

看起来放缓来自加入权限表，权限表代表哪些从业者管理哪些客户端。

pooling.ClientAccountInheritedRateGroup，pooling.ClientAccountFirstContact并且pooling.PractitionerAccountFirstContact是所有视图，所有视图都以亚秒选择返回完整数据集。

是的，现在进行实际查询（对不起，它有点像怪物）：

with h (distance, id, name, parentid, [path]) as ( 
select 
    0,
    pa.id,
    pa.name,
    null,
    convert(varchar(80), ltrim(str(pa.id))) as node_seq
from     
    pooling.practitioneraccount pa
    left outer join pooling.practitioneraccountrelation as par
        on pa.id = par.childid
where  
    pa.id = @PractitionerAccountId
    or (@PractitionerAccountId is null and …

我希望提高 SQL Server 2008 中视图的性能。这个视图存在于一个报告数据库中，非技术人员广泛使用该数据库来基本上对一个人的所有这些属性进行非规范化。

这是一个非常复杂的长期运行视图。我们有超过 1900 万人，每一列都有很多逻辑。例如，有一个关于一个人是否已故的指标，它依赖于三个 CTE（公共表表达式）和一个 case 语句。

基本上，这是一场噩梦。

我需要想办法提高性能。无法将其更改为表格 - 数据必须准确无误。将其更改为索引视图是正确的 - 它使用来自多个数据库的数据。我无法真正修改列结构，因为它会破坏许多现有报告。

工具箱中是否有可能有帮助的工具？我想知道存储过程或函数是否有帮助。也许是一个带有计算列的表？我将能够每晚提取此人的识别信息并将其存储到表格中，但绝大多数列依赖于实时数据。

一些 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 …

我有一个包含连接几个表的查询的过程，但我遇到了一些性能问题。

主表（这是一个巨大的表）有一个 PK 和一些 NC 索引。

CREATE TABLE [dbo].[TableA]
(
    [TableAID] [bigint] NOT NULL,
    [UserID] [int] NOT NULL,
    [IP1] [tinyint] NOT NULL,
    [IP2] [tinyint] NOT NULL,
    [IP3] [tinyint] NOT NULL,
    [IP4] [tinyint] NOT NULL
    CONSTRAINT [PK_TableA] 
        PRIMARY KEY CLUSTERED  ([TableAID] ASC)
) ON [PRIMARY]


CREATE NONCLUSTERED INDEX [idx_1] ON [dbo].[TableA] 
(
    [UserID] ASC
)


CREATE NONCLUSTERED INDEX [idx_2] ON [dbo].[TableA] 
(
    [IP1] ASC,
    [IP2] ASC,
    [IP3] ASC,
    [IP4] ASC
)

这是性能不佳的查询：

SELECT DISTINCT a.UserID, a.IP1, a.IP2, a.IP3, a.IP4
    FROM [dbo].[TableA] …

我使用 PostgreSQL 9.6。

我有一个连接 17 个表的查询，其中 9 个有几百万行。查询运行良好，但本周其性能迅速下降。EXPLAIN 的输出没有帮助（所有扫描都是索引扫描，除了非常小的表），我不得不尝试从查询中删除表以隔离导致降级的表。

事实证明，一个包含 40 行的不起眼的表破坏了查询：800 ms 没有该表，而有 30 s。我在桌子上运行了 VACUUM FULL，它运行了大约一秒钟，现在性能恢复正常。

我的问题：

1. 什么可以解释 <10kb 的表像这样破坏性能？
2. 以后如何避免同样的问题？

在调试过程中，我对另一台服务器进行了基本备份，因此我有两个文件系统级别的数据库副本，其中一个我没有运行 VACUUM FULL。当我使用 pgAdmin 登录到 unvacuumed 副本时，我收到以下消息：

表“public.clients”上的估计行数与实际行数显着不同。您应该在此表上运行 VACUUM ANALYZE。

unvacuumed 表有 40 行计数和 0 估计。以下是屏幕截图中的其余统计数据。

我们在单个表上进行简单更新需要很长时间时遇到问题。该表包含约 500 万行。

这是表：

CREATE TABLE Documents (
    GeneratedKey varchar(32) NOT NULL,
    SourceId int(11) NOT NULL,
    Uri longtext,
    ModifiedDateUtc datetime NOT NULL,
    OperationId varchar(36) DEFAULT NULL,
    RowModifiedDateUtc datetime NOT NULL,
    ParentKey varchar(32) NOT NULL,
    PRIMARY KEY (SourceId, GeneratedKey),
    KEY IX_RowModifiedDateUtc (RowModifiedDateUtc),
    KEY IX_ParentKey (ParentKey),
    KEY IX_OperationId (OperationId(36))
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

这是更新查询：

UPDATE Documents
SET OperationId = 'xxxx'
WHERE SourceId = 12345
AND ParentKey = '0965b3983ceb0e8e41ab47b53e37d0f3';

此查询更新约 80k 行，大约需要60 秒才能完成，更新的行越多，所需的时间越长，这会导致超时。索引IX_ParentKey基数是 ~830k。请注意，具有相同WHERE子句的选择返回非常快（< 1s）。

查询分析：

starting …