小编sha*_*oth的帖子

我有这张桌子：

CREATE TABLE [dbo].[Accounts] (
    [AccountId] UNIQUEIDENTIFIER UNIQUE NOT NULL DEFAULT NEWID(),
    -- WHATEVER other columns
);
GO
CREATE UNIQUE CLUSTERED INDEX [AccountsIndex]
    ON [dbo].[Accounts]([AccountId] ASC);
GO

这个查询：

DECLARE @result UNIQUEIDENTIFIER
SELECT @result = AccountId FROM Accounts WHERE AccountId='guid-here'

使用由单个索引查找组成的查询计划执行 - 正如预期的那样：

SELECT <---- Clustered Index Seek

此查询执行相同的操作：

DECLARE @result UNIQUEIDENTIFIER
SET @result = (SELECT AccountId FROM Accounts WHERE AccountId='guid-here')

但它是按照一个计划执行的，其中索引查找的结果与一些常量扫描的结果左外连接，然后输入计算标量：

SELECT <--- Compute Scalar <--- Left Outer Join <--- Constant Scan
                                      ^
                                      |------Clustered Index Seek

什么是额外的魔法？常量扫描后跟左外连接有什么作用？

根据这个答案，除非在用于限制的列上建立索引，否则查询将不会从索引中受益。

我有这个定义：

CREATE TABLE [dbo].[JobItems] (
    [ItemId]             UNIQUEIDENTIFIER NOT NULL,
    [ItemState]          INT              NOT NULL,
    [ItemPriority]       INT NOT NULL,
    [CreationTime]       DATETIME         NULL DEFAULT GETUTCDATE(),
    [LastAccessTime]     DATETIME         NULL DEFAULT GETUTCDATE(),
     -- other columns
 );

 CREATE UNIQUE CLUSTERED INDEX [JobItemsIndex]
    ON [dbo].[JobItems]([ItemId] ASC);
 GO

CREATE INDEX [GetItemToProcessIndex]
    ON [dbo].[JobItems]([ItemState], [ItemPriority], [CreationTime])
    INCLUDE (LastAccessTime);
GO

和这个查询：

UPDATE TOP (150) JobItems 
SET ItemState = 17 
WHERE 
    ItemState IN (3, 9, 10)
    AND LastAccessTime < DATEADD (day, -2, GETUTCDATE()) 
    AND CreationTime < DATEADD (day, …

我们最近观察到在 Standard3 性能层中运行的 SQL Azure 数据库出现严重的性能下降 - CPU 利用率在短短一小时内从 10% 到 50% 上升到接近 100%。因此，我们将性能层更改为 Premium2，CPU 利用率立即下降到 8% 左右。

Standard3 声称提供 100 个 DTU，Premium2 声称提供 250 个 DTU。这意味着 8% 的 P2 只是 20 个 DTU，这与使用 Standard3 中的所有 100 个 DTU 相去甚远。

这些 DTU 是否不同？否则，从 100 DTU 性能层切换到 250 DTU 性能层时，这种利用率突然下降怎么可能？

我有一个这样的 SQL 查询：

SELECT A, B, (CASE WHEN C=0 THEN 0 ELSE 1 END), COUNT(D)
FROM SomeTable
GROUP BY A, B, (CASE WHEN C=0 THEN 0 ELSE 1 END)

在庞大的数据集上，实际执行计划大部分时间都归因于对应于逻辑操作 Aggregate和物理操作 HashMatch 的节点。

更改列和条件在列表中的GROUP BY列出顺序会影响性能吗？

我们的 SQL Azure 数据库包含一个SELECT每天运行一次的大量语句。沉重的SELECT语句不包含锁定提示。最近我们观察到生产中的一些停顿，这sys.dm_exec_requests是那段时间显示的内容......运行时间最长的查询是SELECT具有PAGEIOLATCH_SH等待类型的繁重查询。接下来是其他查询——最常见的INSERT是具有PAGEIOLATCH_EX等待类型的语句，所有语句都运行了几十秒而不是立即完成。所以基本上，SELECT只有重才会干扰其他查询。

我该如何解决？我可以接受SELECT缓慢运行的繁重工作，但不应中断其他查询。

我有以下定义：

CREATE TABLE [dbo].[JobItems] (
    [ItemId]            UNIQUEIDENTIFIER NOT NULL,
    [ItemState]         INT              NOT NULL,
    [ItemCreationTime]  DATETIME         NULL DEFAULT GETUTCDATE(),
    [ItemPriority]      TINYINT          NOT NULL DEFAULT(0),
    [ItemRefreshTime]   DATETIME         NULL,
    -- lots of other columns
    CONSTRAINT [PrimaryKey_GUID_HERE] PRIMARY KEY NONCLUSTERED ([ItemId] ASC)
);

CREATE UNIQUE CLUSTERED INDEX [JobItemsIndex]
    ON [dbo].[JobItems]([ItemId] ASC);

CREATE INDEX [GetTaskToProcessIndex]
    ON [dbo].[JobItems]([ItemState], [ItemPriority], [ItemCreationTime])

以及以下查询：

SELECT TOP(1) ItemId FROM JobItems
WHERE ItemState = 5 OR
   ( ( ItemState = 11 ) AND ( DATEDIFF( SECOND, ItemRefreshTime, GETUTCDATE() ) > 14 …

到目前为止，我尝试了多次索引重组查询。它们看起来像这样：

ALTER INDEX ALL ON TableName REORGANIZE

这样的查询可能需要几个小时，但它看起来不会干扰其他数据库操作。对于某些表，它的影响几乎为零，但对于某些表，它实际上节省了 15% 的整体数据库空间。

如果我每周左右对所有索引运行此查询会怎样？有什么理由不这样做吗？

在 SQL Server 中，我部署了一个带有UNIQUE约束的表：

CREATE TABLE [dbo].[Something] (
    [IdentityId]  UNIQUEIDENTIFIER UNIQUE NOT NULL DEFAULT NEWID()
    -- Whatever else...
)

这使得 SQL Server 创建一个唯一索引来支持约束。该索引将自动生成名称，看起来像

UQ__tmp_ms_x__1F778345BD

where 的UQ意思是“独特的”，其余的都很好，对我来说是随机的。如果我对同一个表有两个唯一约束，它们看起来就像两个随机字符串，这不是很方便。

创建唯一约束时，是否可以指定在后台创建的索引的名称？

假设我有一个Stuff包含一列的表，但City没有包含该列的索引。我填充表格。然后我决定创建一个索引：

CREATE INDEX [StuffOnCityIndex] ON [dbo].[Stuff](City ASC);

并且数据库确认CREATE INDEX成功。

新创建的索引会立即包含表中的所有现有条目还是会在“后台”缓慢构建？换句话说，如果我认为创建索引会提高性能，那么我会在CREATE INDEX完成后立即看到这种改进吗？

当我使用浏览器连接到某个电子商务网站时，我使用的 HTTPS 使用的证书（或多或少）保证example.com确实是example.com.

现在我连接到 Internet 上某处的 SQL Server - 例如它可能是 SQL Azure，然后我只连接到像abcdef.database.windows.net. 有可能那里有一个假服务器，然后我暴露了我的敏感数据。我没有发现任何证据表明在连接到 SQL Server 时使用了证书或任何等效物。

如何确保 SQL Server 主机标识？

这是此处表定义的一部分：

CREATE TABLE [dbo].[JobItems] (
[ItemId]            UNIQUEIDENTIFIER NOT NULL,
-- lots of other columns
CONSTRAINT [PrimaryKey_GUID_HERE] PRIMARY KEY NONCLUSTERED ([ItemId] ASC)
);

CREATE UNIQUE CLUSTERED INDEX [JobItemsIndex]
ON [dbo].[JobItems]([ItemId] ASC);

这是一些遗留设计，所以请不要问“为什么”。无论如何，当我查找索引列表时，我看到有两个索引 - 其中一个是JobItemsIndex，另一个是PK-GUID-HERE，它们都用于JobItems表。

我的问题是...

为什么需要一个单独的索引来维护 PK，当我已经拥有JobItemsIndex它是唯一的并且包含非常相同的列并且适合维护 PK 约束时？