标签: sql-server

我在这里似乎有类似的问题，但似乎没有一个答案符合我正在寻找的-

假设我有一张这样的桌子：

另一个像这样：

我想在第一个表上输出带有左连接的第二个表，其中包含每个指定用户的“类型”总数（基本、中、高），因此它需要类似的内容：

我已经尝试过--Count(case when <table>.[type] = 'Elementary' then 1 else 0 end) AS ElementaryCount,，但这只是让我获得整个表，而不是左连接的用户。

有人知道我该怎么做吗？

我在 SQL Server 2016 中运行alter index reorganize一些列存储索引并收到死锁消息。

永远是reorganize受害者吗？因为我不想导致其他工作失败，并且我正在考虑添加一个set deadlock_priority. 或者这是内置的alter index声明？

我继承了一个多年前由软件供应商安装的应用程序（以及相关的 MS SQL 数据库）。目前我们没有任何类型的供应商支持。除了使用应用程序之外，我们还独立于应用程序访问数据库，通常直接更新数据库并查询数据以进行报告。

为了提高性能，我删除了一些不必要的索引并创建了其他索引。当应用程序执行某些任务时，这会导致应用程序出现错误。应用程序不会显示任何类型的错误消息，并且似乎执行正常，但应用程序未按预期更新数据库。我无法访问源代码。

我的理论是，应用程序在其查询之一的 with(index) 语句中显式指定已删除的索引。这将导致服务器返回错误而不是完成查询，并且如果应用程序抑制错误，用户将不会意识到某些表已更新而其他表未更新。还有哪些其他想法可能导致这种行为？

假设我的理论是正确的，我仍然相信索引实际上是不必要的，并且应用程序不应该指定索引。也许解决方法是创建一个具有相同名称的新索引，但列数尽可能少。有没有办法创建没有列的索引？创建与聚集索引具有相同列的非聚集索引是否是最有效的？在这种情况下，优化器会做什么 - 它是否仍然制定计划包含这些仅引用聚集索引的“坏”索引，或者它会知道忽略 with(index) 请求吗？

我确实运行了跟踪来查看应用程序正在运行哪些查询。我收到了一堆 RPC 调用，例如“exec sp_cursorfetch”和“exec sp_cursorexecute”（我不明白），而不是实际的 SQL。也许我会在一个单独的问题中询问这些问题，但如果你知道我如何将这些语句解释或解码为常规 SQL，那么这至少可以让我证实我的理论。

SQL Server在进行备份时，是先将数据读入内存再写入备份文件，还是直接从数据文件中读取数据，直接写入备份文件？我找不到任何有关此的信息，但我想它直接从数据文件读取并写入备份文件。从资源监视器中，我看到了这一点：

正如您所看到的，SQL Server 从 mdf 文件中读取数据并将其写入备份文件。但由于我找不到任何相关信息，所以我只想确认一下。

我正在从使用对象 ID 和属性类型作为聚集索引的属性表迁移一些存储“键值”样式的数据（我也尝试过作为非聚集索引）：

CREATE TABLE [dbo].[#attrs](\n    [DataMigrationEventObjectID] [int] NOT NULL,\n    [AttributeType] [varchar](128) NOT NULL,\n    [AttributeValue] [varchar](255) NULL\n) \nCREATE CLUSTERED INDEX pk ON #attrs ([DataMigrationEventObjectID],AttributeType);\n

我添加了属性值来选择值，因为数据库中的属性表有很多其他数据，我可以仅为此迁移事件选择它。使用我的测试数据集来填充此表的查询会插入约 3k 行，并且运行时间不到一秒（我的数据集中总共约有 50 个对象，每个对象都有多个属性）。

查询中表的连接如下所示，连接聚集索引：

        INNER JOIN #attrs obj_gvn\n        ON obj_gvn.DataMigrationEventObjectID = obj.DataMigrationEventObjectID\n        AND obj_gvn.AttributeType = \'GivenName\'\n

通过对该临时表进行 14 个联接，查询将在几秒钟内完成。如果有 15 个连接，查询需要一分钟，如果有 16 个以上连接，则半小时后仍在运行。

我已经检查了所有联接是否存在意外条件，这会导致返回太多行，当它在 1 分钟内返回时，它只返回正确的行，所以我不认为存在意外的笛卡尔联接。设置 MAXDOP 值不会影响它，并且查询运行一分钟时返回的查询计划不会标记任何问题。

对于 SQL，我错过了什么，导致它在聚集索引上进行大量联接，理论上应该很快，而且记录数量如此之少？

我无法获得实际执行计划，因为查询未完成，并且因为它使用临时表，所以我无法获得其估计计划。我尝试将临时表捏造为数据库中的真实表并生成估计计划，但 2 分钟后该计划仍未生成，因此看起来延迟是在“创建计划”方面

粘贴查询的缩短版本的计划：brentozar.com/pastetheplan/ ?id=Hy76dd92i

我已经更新了数据库的统计数据以防万一，但它仍然没有生成计划。

我过去处理过越来越多有问题的连接查询，其中计划编译仍然是即时的。我觉得它在“生成计划”步骤失败这一事实一定意味着什么。

不幸的是，更新到最新的 CU 没有帮助。 …

我需要编写一个存储过程来更新数据库中的链接引用。链接可以包含在几个包含 JSON 的 nvarchar 字段中（可能包含一些 url）。

为此，我每次迭代分批更新表 8129 个项目，这样机器就不会挂起（理论上）。

但现在代码似乎无论如何都挂起，它不会打印任何消息，并且程序继续运行（不影响任何数据）很多分钟，直到我必须终止该程序（同时似乎没有影响任何数据） 。

如果我尝试在玩具示例上使用相同的逻辑，我不会遇到任何问题，所以我认为我的问题是由于表很大（几十万行）这一事实造成的。

这里是一个正在运行的最小示例，更大的表上完全相同的代码显然没有执行任何操作（使用 SQL Server 2019 进行测试）。

程序代码：

ALTER PROCEDURE [dbo].[SiteUrlChangeURL]
    @FullOldUrl nvarchar(500),
    @FullNewUrl nvarchar(500)
AS
BEGIN
    -- SET NOCOUNT ON added to prevent extra result sets from
    -- interfering with SELECT statements.
    SET NOCOUNT ON;

    SET @FullOldUrl = ISNULL(@FullOldUrl,'');
    SET @FullNewUrl = ISNULL(@FullNewUrl,'');

    IF ( LEN(@FullOldUrl) <= 0 OR LEN(@FullNewUrl) <= 0 )
    BEGIN 
        PRINT('Invalid parameters');
        RETURN 1;
    END

    --ARTICLE
    RAISERROR ('updating articles',0,1) WITH NOWAIT;
    WHILE 1=1
    BEGIN
        UPDATE …

我使用定制的 Stack Overflow 数据库（180GB）并运行一个简单的更新查询：（Users 表上只有一个聚集索引）

Begin Tran
Update U set U.Reputation=100000 
from StackOverflow.dbo.Users as U 
where U.CreationDate = '2008-10-10 14:26:33.540'

查询计划：

此查询会导致锁升级。我无法在另一个窗口中使用同一个表运行查询：

select * from StackOverflow.dbo.Users as U where U.id=11

如果我option (maxdop 1)在查询末尾添加以避免并行，则一切都很好（计划）。

在较小的 Stack Overflow DB (StackOverflow2013 - 52GB) 中不会发生锁升级（计划）。

如何确定导致升级的数据量？

我使用 SQL Server 2019。数据库兼容级别为 150。

表信息：

• StackOverflow2013.dbo.Users -- 2 465 713 行；45 184 页
• StackOverflow.dbo.Users -- 8 917 507 行；143 667 页

我需要删除所有三个表中 UserIndex = 1 和 ItemNumber = 5202 的记录，所有这些记录都在单个查询中。我正在使用 SQL 2008 R2。

表用户信息1

表用户信息2

表用户信息3

我尝试将此查询与两个表一起使用，但它不起作用：

DELETE ItemInfo1, ItemInfo2 
FROM ItemInfo1 
LEFT JOIN ItemInfo2 
    ON ItemInfo1.UserIndex = ItemInfo2.UserIndex 
WHERE ItemInfo1.UserIndex = 1;

• 我们有两个节点 Windows Server 集群，每个节点上安装了 SQL Server（2019 标准版）集群实例
• 有 500 个活动数据库
• 没有配置任何可用性组或任何其他 HA 解决方案
• 所有数据库均处于简单恢复模式
• VLF 数量和尺寸都不是很大
• 两个节点都是虚拟化的 Windows Server 2019，具有 64 GB 内存和 16 核。

修补被动节点并重新启动后，我们尝试故障转移到该节点。但令人惊讶的是，启动 SQL Server 服务大约需要 10 分钟，该服务挂起在更改挂起状态。在不打补丁的常规情况下，大约需要 10 秒。我从微软文档中得知，停机时间取决于故障转移时间和数据库升级脚本执行的总时间：

这一过程导致整个故障转移集群升级期间的停机时间仅限于一次故障转移时间和数据库升级脚本执行时间。

在我看来，这个停机时间似乎很长，只是在寻找以某种方式减少它的方法。如果您有任何建议，我将非常乐意倾听。

在 SQL Server 中，我们可以使用它set statistics profile on来启用会话分析。然后您可以执行任何一条语句，相应的执行计划将以表格形式显示。是否可以将这种流行的表单计划保存到某个表中，以便我可以对其进行过滤？

此平板电脑表单执行计划的示例如下所示：