小编J.D*_*.D.的帖子

非聚集索引使用聚集索引的键定位行与该表没有聚集索引且非聚集索引通过 RID 定位行之间是否存在性能差异？

不同级别的碎片是否也会影响这种性能比较？（例如，在这两种情况下，表的碎片率为 0%、50%、100%。）

如果该表被重命名，表上的外键关系会发生什么变化？

我有一个数据库，它将在不同用户的多种相关类型的应用程序之间共享。我希望能够限制每个数据库用户基本上可以完全控制他们自己的对象，而只能对他们没有创建的数据库的其他对象进行读取访问。

这是可能的，实现这一目标的最佳方法是什么？

我有一个 SQL 查询，我需要每秒运行大约 12 个小时。这是一个非常简单的查询，它将一些数据记录到一个孤立的表中。现在我一直让它在我的本地 SSMS 客户端中WHILE循环运行，并且我WAITFOR DELAY '00:00:01'习惯于在每次迭代之间暂停 1 秒。

如果我想将其移动到代理作业中，最好安排作业在这 12 小时内每 1 秒运行一次，还是保持查询原样并在早上启动一次作业，以便查询管理如何通常它会运行。（要记住的一件事是，查询通常足够快，以至于它的运行时间是亚秒级，但很少需要几秒钟才能完成执行。）

我想根本问题是，有一个连续运行 12 小时的工作，还是一个运行大约 43,000 次（每秒一次，持续 12 小时）的工作更好？

偶尔（但不常见）我的 SQL 服务器会花费看起来很奇怪的时间来生成执行计划。为以下相当简单的查询生成估计的执行计划只花了 37 秒：

SELECT *
FROM Table1
WHERE IndexedIntField1 = 12345
    AND NonIndexedVarcharField IN ('Value1', 'Value2', 'Value3')

这个查询的结果数量大约为 500 行（来自一个包含大约 100 亿行的表），执行计划本质上是一个非聚集索引查找和键查找。

这是正常的吗？

编辑：

• 表 1 是一个实际的物化常规基于磁盘的表（这里没有什么特别的）。
• 它大约有 30 列宽。
• 上面有 1 个聚集索引和 4 个非聚集索引。
• 我的示例中的“IndexedIntField1”是 2 个非聚集索引中索引键的一部分，并且是第三个非聚集索引上的包含列。
• “NonIndexedVarcharField”不是键，也不包含在任何索引中。
• 我们每周至少更新一次表和索引的统计信息（有时一天一次或更多次）
• 此表上没有花哨的计算列
• 表上的索引非常简单，键列/包含列中只有几个字段，除了将“IndexedIntField1”作为键列的索引之一确实包含大约 15 列（因此它是一个相当大的索引） ）。

如果以下循环查询在循环过程中被终止，是所有插入还是仅当前一个回滚？

DECLARE @LoopId INT = 1;

WHILE (@LoopId < 100)
BEGIN
    INSERT INTO Table2
    SELECT Field1 
    FROM Table1
    WHERE ForeignKeyField = @LoopId

    SET @LoopId = @LoopId + 1;
END

我对常规行存储索引如何存储的理解是一种 b 树数据结构，但我想知道由于列存储索引的不同性质，使用什么类型的底层数据结构？

如果我有两台服务器（服务器 A 和服务器 B）属于同一个可用性组故障转移集群，并且在服务器 A 上运行的查询具有使用并行化的执行计划，那么该查询是否可以使用处理器的内核在服务器 B 上？

是否可以在数据库中创建自定义架构，以便在该数据库中对 dbo 架构具有只读访问权限的用户可以设置为能够为自定义架构创建和修改实体？

SQL Server 表触发器每秒可以处理多少事务？如果我有一个每秒插入 1,000 次的高度事务性表，该表上的插入触发器是否可靠地每次触发？

我有一个过程，它在数百个数据库中动态运行查询，这些数据库都具有相同的确切架构，并将结果聚合到临时表中。该查询仅涉及 3 个表（每个表都在数百万行的 10 到 100 之间，但我总共只提取了大约 50,000 行数据）。

在查看查询的汇总 IO 统计信息（通过 StatisticsParser.com - 大声喊出 Richie Rump）时，它显示创建了一个工作表，并且该工作表上有大约 550,000 个 LOB 逻辑读取。查询中所有表的常规逻辑读取总数略低于大约 400,000 次逻辑读取。

查询中的实际表都没有使用任何 LOB 数据类型，那么这到底意味着什么，它是否是我查询中瓶颈的潜在来源？

（顺便说一句，我拉回的 50,000 行数据仅相当于大约 3 MB 的数据，但我的查询在第一次运行时需要大约 10 秒才能运行（例如，当表的数据页仍在加载到内存中时） )，然后在后续运行中不到一半的时间，因此尝试查看我是否可以始终接近 <= 4s 基准测试，以及这些 LOB 逻辑读取是否与之相关。）

更新：这是一个类似的示例查询（再次查看它，我可能会发现 LOB 逻辑读取的来源）。

过程签名： sp_StoredProc_ToGetData (@IdsTable TVP (Id INT), @StartDate DateTime, @EndDate DateTime)

sp_StoredProc_ToGetData 内部的查询：

SELECT Id
INTO #IdsTableTemp
FROM @IdsTable;

-- This query is ran using dynamic SQL but for the example simplicity this is just the root …