我们确实有几台服务器，一台专用于没有 SQL 的网站，另一台服务器专用于 SQL。

现在运行 SQL 的服务器非常强大，但有时服务器 CPU 只是达到 100%。

这是几个屏幕截图，显示了正在发生的事情。

CPU 已满：

CPU运行正常：

如您所见，服务器非常强大。

补充说明。

1. 我们正在运行 nopcommerce 版本 3.70
2. 该网站已由其他开发人员进行了大量定制。
3. 该网站有大约 4000 - 5000 种产品。
4. 当 CPU 达到最大值时，加载时间令人震惊。> 30 秒，有时超过 1 分钟。

有没有人能够对可能发生的事情有所了解，或者指导我完成一些检查。

干杯

更新：以下两个屏幕截图是@S4V1N 建议我运行的两个查询的结果。

我需要在同一个表中查找可能匹配的客户记录。逻辑如下。然而，这似乎在 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
            )
        )
    )

我们公司有 5 个不同的数据库。多个数据库中没有一个涉及或利用跨数据库连接。我们有充足的资源和预算。

我们公司正在争论：

• 1 个服务器实例上的 5 个数据库，

• 或 5 个不同服务器上的 5 个数据库。

问题：如果我们将所有内容都放在一台服务器上，可能会出现哪些具体问题、障碍问题？我的背景不是 DBA，所以想学习可以与团队讨论的示例。

背景：

公司 1 个服务器实例的论据：我们有带有故障转移群集的“资源调控器”和“AlwaysOn 可用性组”。资源调控器将处理数据库之间的内存、CPU、io 工作负载。因此，与 AlwaysOn DR 一起，它可以处理失控的查询、糟糕的设计、内存问题。

每个数据库 100GB，关键公司信息，最少 5000 万行

我们每秒处理 300 笔交易

RTO = 10 分钟

我面前有一个有趣的问题。有一个数据库有大约 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 …

v8.4 和 v9.2（是的，我知道它们过时且不受支持，但我对此无能为力。）

我管理（但未设计）的数据库中的某些表在 CHARACTER VARYING(256) 字段上具有 btree 索引。即使字段值不全为空，其中的数据长度也不超过 12 个字符。

是的，这些列的物理表存储是高度压缩的，但是 btree 索引呢？如果将列更改为 VARCHAR(12)，索引会更有效吗？

谢谢

设置

我在基于 SSD 的四核虚拟专用服务器 (VPS) 和 Debian Linux (8) 上运行 PostgreSQL 9.4.15。相关表有大约 200 万条记录。

记录经常被插入，甚至更频繁地（不断——至少每隔几秒钟）更新一次。据我所知，我已经为这些操作准备了所有适当的索引，以便快速执行，而且绝大多数时间它们确实会立即执行（以毫秒为单位）。

问题

然而，每隔一小时左右，其中一个UPDATE查询就会花费过多的时间——比如 10 秒或更长时间。当这种情况发生时，它通常就像“一批”被“阻塞”的查询，几乎同时终止。就好像其中一个查询或其他一些后台操作（例如，真空）正在阻止它们。

架构

表 ,items有很多列，但我认为以下是唯一可能与问题相关的列：

• id INTEGER NOT NULL （首要的关键）
• search_vector TSVECTOR
• last_checkup_at TIMESTAMP WITHOUT TIME ZONE

这些是相关的索引：

• items_pkey PRIMARY KEY, btree (id)
• items_search_vector_idx gin (search_vector)
• items_last_checkup_at_idx btree (last_checkup_at)

可能的罪魁祸首

最后，当pg_stat_activity我的日志文件中发出“连接泄漏”警告时，在组装了一个小脚本以转储（所有活动 Postgres 连接/查询的列表）的内容后，我缩小了可能的罪魁祸首查询/列（假设问题不是外部的，比如行为不端的 VPS）。粗略地说，这些查询似乎一次又一次地出现：

• UPDATE items SET last_checkup_at = $1 WHERE items.id = 123245
• UPDATE items SET search_vector = [..] WHERE items.id = 78901

这些略有解释，但我真的怀疑缺少任何相关内容。偶尔也会出现其他查询（在其他表上），但这些查询通常看起来只是“不走运”而被卷入其中。

现在，即使第一个查询（设置last_checkup_at …

我有一个表，用于表上的多对多关系users来表示用户之间的跟随关系：

CREATE TABLE users (
    id text PRIMARY KEY,
    username text NOT NULL
);

CREATE TABLE followers (
    userid text,
    followid text,
    PRIMARY KEY (userid, followid),
    CONSTRAINT followers_userid_fk   FOREIGN KEY (userid)   REFERENCES users (id),
    CONSTRAINT followers_followid_fk FOREIGN KEY (followid) REFERENCES users (id)
);

CREATE INDEX followers_followid_idx ON followers (followid);

当我想使用与用户相关的数据创建 JSON 响应时，我有两种情况：

• 通过 id 请求单个用户，
• 通过 id 列表请求用户对象数组

用户数据对象应包含两个用户 ID 数组，一个是他们关注的用户，另一个是关注他们的用户。为了创建这两个字段，我使用了以下SELECT语句。

DECLARE follows RECORD;
SELECT  array (select followid FROM followers where userid = Puserid) AS following, …

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

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 查询优化器处理此问题的方式是否有任何不同？