标签: query-performance

我需要在同一个表中查找可能匹配的客户记录。逻辑如下。然而，这似乎在 O(N²) 下执行。有没有办法提高这里的性能？我试过设置索引、散列列并进行比较等，但在大型数据集上的性能仍然很糟糕。我还在下面添加了查询计划。

SELECT
    C1.CustomerId AS Customer1, 
    C2.CustomerId AS Customer2
FROM Customer C1
INNER JOIN Customer C2
    ON 
    C1.CustomerId != C2.CustomerId
    AND
    (C1.FirstName = C2.FirstName OR C1.BirthDate = C2.BirthDate)
    AND
    (
        C1.EmailAddress = C2.EmailAddress
        OR
        C1.MobilePhoneNumber = C2.MobilePhoneNumber
        OR
        (
            C1.HomeAddressLine1 = C2.HomeAddressLine1
            AND
            (
                C1.HomePostCode = C2.HomePostCode
                OR
                C1.HomeSuburb = C2.HomeSuburb
            )
        )
    )

我面前有一个有趣的问题。有一个数据库有大约 100 万个用户帐户，预计每年增长 1-200 万个。该数据库是强 TPT，但此特定查询和所涉及的表不涉及任何 TPT 内容。

当指定第二个数据点（即电子邮件地址和姓氏、公司等）时，sproc 和视图的当前设计需要大约 15 秒来执行 (x2)。该数据库是 SQL Azure P11，但它不是 DTU 绑定查询，升级到最高可用产品 (P15) 对结果没有影响。

下面是 sproc、视图和执行计划。在过去 24 小时内重建或重组了所有索引，并更新了所有统计信息。例如，在查看数据时，历史电子邮件地址 (1..N) 的概念目前正在使用 aCROSS APPLY来获取最新的，这可以防止索引视图，可以通过简单地连接历史电子邮件地址和持久化来解决它们在一个列中。

许多数据库在 nvarchar(4000-max) 列中使用 JSON，所有这些列都有一个公开值并启用索引的计算列。范式必须支持分页，我正在寻找有关如何优化它的反馈/建议。

在这一点上，更改表结构不是一个可行的选择，尽管我可以通过一点点操作看到前进的道路。有没有人对我应该首先看哪里有任何想法？我已经对未知的重新编译和优化进行了测试，以查看是否有任何影响，如果有，则可以忽略不计。

注意：一些业务逻辑（专有列名被删除或修改，sproc和view不能按原样执行，但在功能上与源相同。

执行计划和视图

程序

CREATE PROCEDURE [dbo].[spGetUserDetailsDynamic] @JsonFilter NVARCHAR(MAX)
AS /* Page number*/
DECLARE @Page AS INT = JSON_VALUE(@JsonFilter, '$.requestPaging.page');
/* Number of records on the page*/
DECLARE @Size AS INT = JSON_VALUE(@JsonFilter, '$.requestPaging.size');

IF (@Page = -1)
    SET @Page = 1;

IF (@Size …

如果我直接在 SQL Server Management Studio 中执行我的（简单）查询...

SELECT auftrag_prod_soll.ID 
  FROM auftrag_prod_soll 
 WHERE auftrag_prod_soll.auftrag_produktion = 51621 
   AND auftrag_prod_soll.prod_soll_über = 539363
 ORDER BY auftrag_prod_soll.reihenfolge

......一切都很好，很快......

Table 'auftrag_prod_soll'. Scan count 2, logical reads 6, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
  CPU time = 0 ms,  elapsed time = 102 ms.

...因为 SQL Server 会根据两个过滤条件选择合理的执行计划：

另一方面，如果我的应用程序使用游标执行相同的查询......

declare @p1 int
declare @p3 int
set @p3=4
declare @p4 int
set @p4=1 …

最近，我正在解决一个奇怪的性能问题，该问题影响了应用程序的生产环境，但不影响任何较低的环境。我设法用这个查询以最简单的形式复制了这个问题：

SELECT product_id, dbo.TranslateStatusToActive(status_id) FROM prod_Products

TranslateStatusToActive是一个非常简单的标量 UDF，它基本上只是连接给另一个表的值，并根据case语句返回 1 或 0 。我会发布代码，但它是供应商编写的功能，我今天对被起诉并不特别感兴趣。（是的，逻辑可以内联。是的，它解决了性能问题。是的，我们已经说服供应商实施更改。这不是我的问题。）

在生产中执行时，查询需要 10 到 20 秒才能返回结果。在开发中，相同的查询在不到 3 秒的时间内返回。执行计划几乎相同，除了显示 CPU 时间在生产中约为 15000 毫秒，其他地方为 3000 毫秒。

我怀疑存在一些环境差异，因此我设置了另一台服务器来尽可能地复制生产条件：我确保 CPU 的数量、分配给 SQL Server 的内存量以及特定的补丁级别 (13.0.0.1)。 4451) 相同。

我将生产数据库的副本恢复到这个新的沙箱服务器，令我惊讶的是，查询的执行速度与它在开发中的执行速度一样快。再一次，计划和数据是相同的，除了额外的 CPU 时间。执行计划中列出的等待类型相同，并且在每个环境中彼此相差几毫秒。

不知道接下来要做什么，我optimize for ad hoc workloads在生产服务器上启用了。这解决了性能问题！但是有一件事：其他环境都没有启用此设置。我一直在测试期间定期清除每个环境中的程序和系统缓存，所以我认为这不是更改设置导致重新编译的结果。

问题

• 尽管有相同的计划和几乎相同的系统，但什么可能导致 UDF 在每个环境中运行如此不同？
• 为什么需要optimize for ad hoc workloads启用生产环境才能与未启用它的其他环境一样好？
• 是否有一些我没想到检查的设置可能会导致如此大的差异？

开发是共享的，而生产目前仅由该应用程序使用。第三个盒子的用法和生产的盒子几乎一样。我几乎清除了他们发出DBCC命令的每个缓存。开发环境经常用作培训系统，所以我相当确信这不是计划缓存问题。

与第三个框的唯一区别是没有连接到它的应用程序，但是在我在生产中测试该功能时几乎没有使用应用程序，所以区别在于，基于我在这种环境中工作的经验，微不足道。我唯一不能做的就是重启生产服务器，但微软的文档明确指出启用optimize for ad hoc workloads不会清除或影响任何现有计划，所以我看不出有什么区别。

LTRIM与RTRIM结合使用时，您放置的操作顺序是否重要ISNULL？例如，以下面的示例为例，用户可能会在字段中输入一堆空格，但我们将其输入修剪为实际NULL值以避免存储空字符串。

我正在执行以下TRIM操作ISNULL：

DECLARE @Test1 varchar(16) = '    '

IF LTRIM(RTRIM(ISNULL(@Test1,''))) = ''
BEGIN
    SET @Test1 = NULL
END

SELECT @Test1

这适当地返回一个真NULL值。现在让我们ISNULL放在外面：

DECLARE @Test2 varchar(16) = '    '

IF ISNULL(LTRIM(RTRIM(@Test2)),'') = ''
BEGIN
    SET @Test2 = NULL
END

SELECT @Test2

这也返回一个NULL值。两者都适用于预期用途，但我很好奇 SQL 查询优化器处理此问题的方式是否有任何不同？

我在数据库中有一个表 t (PostgreSQL 10.4)：

\d t;
                Table "public.t"
  Column  |          Type          | Collation | Nullable | Default 
----------+------------------------+-----------+----------+---------
 sn       | character varying(11)  |           |          | 
 site     | character varying(50)  |           |          | 
Indexes:
    "site_2018_idx" btree (site), tablespace "indexspace"
    "sn_2018_idx" btree (sn), tablespace "indexspace"

我需要为特定站点找到不同的 'sn，我这样做：

SELECT DISTINCT sn FROM t WHERE site='a_b301_1' ORDER BY sn ;

它可以工作，但速度很慢，返回 75 个不同的“sn”值大约需要 8 分钟！有没有办法加快速度？解释分析给出了这个输出：

QUERY PLAN                                                                                 
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=42873094.21..42873103.25 rows=3615 width=12) (actual time=190431.413..190431.417 rows=75 loops=1)
   Output: sn
   Sort Key: t.sn
   Sort Method: quicksort …

我有一个较早执行缓慢的查询。后来我发现它没有并行运行，这使得查询执行速度变慢。

查询涉及一个 big view，然后使用大量temp tablesand查询视图sub query。

我UDF从视图中删除了一个并使用inline functions并使用了一个标量TVF，然后它开始在parallel execution.

这几天一切顺利，有一天我注意到查询运行缓慢。于是查了一下执行计划，发现查询是在串行模式下执行的。我检查了查询的计划缓存，我看到了很多涉及该视图的缓存计划。我删除了不并行的计划，然后查询运行得很快。

现在我每天早上都这样做以强制查询并行运行。

额外细节：

1. SQL Server 2016 标准版
2. 查询通过 LINQ-SQL 从 dot net 应用程序生成。所以临时查询。

如何强制查询永远并行运行？

我需要按月（和年）分组，我在想：

GROUP BY CAST(YEAR(tDate) AS NVARCHAR(4)) + '-' + CAST(MONTH(tDate) AS NVARCHAR(2))

但是我在网上找到了类似的东西：

GROUP BY YEAR(tDate), Month(tDate)

两者是等价的吗？用第二种比较好？

我有几个表，我试图将它们与以下查询结合起来。我正在使用以下表格：

• LoanOrigination：这包含贷款特征，例如资产价值、贷款期限等。每笔贷款有一个独特的观察。该表在LOAN_ID、SUB_SAMPLE和上建立索引COLLATERAL_TYPE。
• LoanPerformance：这包含了所有贷款的表现LoanOrigination。每一行是一个独特的MONTHLY_REPORTING_PERIOD和LOAN_ID组合，并且该表已被索引两个。
• CollateralData：这包含基于COLLATERAL_TYPE. 这样做的目的是估计贷款对抵押品的当前价值。

下面查询的目的是组合这些表，以便每一行都包含贷款特征以及当月和下个月的拖欠状态。但是，查询速度非常慢。有什么办法可以加快速度吗？

with

COLLATERAL_VALUES as (
    select
        COLLATERAL_TYPE,
        dateadd( day, 1-day(AsOfDate), AsOfDate) as ASOFDATE,
        Value as INDEX
    from LoanData.CollateralData
),

SAMPLE_LOANS as (
    select
        a.*,
        b.INDEX as INDEX_T0
    from LoanData.LoanOrigination a
    join COLLATERAL_VALUES b on b.ASOFDATE = a.ORIG_DATE and b.COLLATERAL_TYPE = a.COLLATERAL_TYPE
    where SUB_SAMPLE = 0
),

LOAN_STATE as (
    select
        a.LOAN_ID,
        MONTHLY_REPORTING_PERIOD AS CUR_DATE,
        CURRENT_ACTUAL_UPB as CUR_UPB,
        LOAN_AGE, …

我正在将数据从一个数据库归档到另一台 SQL 服务器上的另一个数据库。我们正在我们的数据库中归档多个表。最近我们对源数据库的插入增加了，但归档运行速度不够快。我正在考虑将表的归档拆分为单独的作业，但是我可以做些什么来提高查询的性能。

这是估计的执行计划

这是实际的执行计划

实际计划中的 QueryTimeStats 如下

+-----------+---------+-------------+---------+
| Statement | CpuTime | ElapsedTime | Percent |
+-----------+---------+-------------+---------+
|         1 |       3 |           3 | 0.00%   |
|         2 |       3 |           4 | 0.00%   |
|         3 |       0 |           0 | 0.00%   |
|         4 |       1 |           1 | 0.00%   |
|         5 |       0 |           1 | 0.00%   |
|         6 |       1 |           1 | 0.00%   |
|         7 |       6 |           6 | …