标签: sql-server

作为兴趣，如果我想从 SQL Server DBA 过渡到 Oracle，我必须做的主要学习或忘却是什么？

我认为这些概念是相同的，区别仅在于编程语言，但我还没有看到门的另一面。

我已经使用 ALTER INDEX REBUILD 来删除索引碎片。在某些情况下，REBUILD 似乎并没有消除这种碎片。REBUILD 不去除碎片的原因是什么？似乎这种情况尤其发生在小索引上。

我正在尝试使以下 SQL 语句起作用，但出现语法错误：

SELECT A.*, COUNT(B.foo)
FROM TABLE1 A
LEFT JOIN TABLE2 B ON A.PKey = B.FKey
GROUP BY A.*

这里，A 是一个有 40 列的宽表，如果可能，我想避免在 GROUP BY 子句中列出每个列名。我有很多这样的表，我必须在这些表上运行类似的查询，所以我必须编写一个存储过程。解决这个问题的最佳方法是什么？

我正在使用 MS SQL Server 2008。

我目前正在将一些数据导入到遗留系统中，并发现该系统不使用单个聚集索引。一个快速的谷歌搜索向我介绍了 HEAP 表的概念，现在我很好奇在什么使用场景中 HEAP 表应该比集群表更受欢迎？

据我了解，HEAP 表仅对审计表和/或插入发生的频率远高于选择的情况有用。它将节省磁盘空间和磁盘 I/O，因为没有要维护的聚集索引，并且由于非常罕见的读取，额外的碎片不会成为问题。

我正在使用 SQL Server 2012 并且想知道如何分析存储过程

例如，探查器可以捕获存储过程中的每个单独的 SQL 语句，它是什么，运行需要多长时间等？

我正在尝试诊断合并复制存储过程，这必须是合并代理完整运行的一部分。似乎不可能抓住有性能问题的存储过程并再次运行它，因为在这一点上它并不慢。

我很好奇是否可以创建一个包含永远无法更改的列的表，但该表的其他列可以。

例如，我可以想象一个CreatedByUser永远不应更改的列。

SQL Server 中是否有为此提供内置功能，还是只能通过触发器或其他方式实现？

看起来执行 T-SQL 的速度取决于与服务器的网络连接的延迟。我假设如果 SQL Server 没有什么可向客户端报告的，它只会执行直到完成，但测试显示了另一个故事。

create procedure UselessLoop
  @I int
as
declare @D datetime = getdate()
while @I > 0 set @I -= 1
print datediff(millisecond, @D, getdate())

exec UselessLoop 100000

Server    Milliseconds
local     53
nearby    63
faraway   660

exec UselessLoop 1000000

Server    Milliseconds
local     546
nearby    640
faraway   6183

使用 SSMS 对来自不同计算机的同一服务器执行测试。本地从服务器执行，附近在同一个本地网络上，远处是从 500 公里外的另一个办公室执行，通过 1 Gb 光纤连接。

显然，SQL Server 和客户端之间存在一些直接依赖于执行的语句数量的通信。

我使用 Wireshark 查看传输的内容，我不能说我理解那么多，但它是一个 tcp.stream，在 22740 个数据包中交换了总共 26 MB。

一个无用的函数呢？

create function dbo.UDFUselessLoop(@I int)
returns int
as
begin
  declare …

维护全文索引应考虑哪些准则？

我应该重建还是重组全文目录（请参阅BOL）？什么是合理的维护节奏？可以使用哪些启发式方法（类似于 10% 和 30% 碎片阈值）来确定何时需要维护？

（下面的所有内容只是详细说明该问题并显示我到目前为止所想的内容的额外信息。）

额外信息：我的初步研究

有很多关于 b 树索引维护的资源（例如，这个问题、Ola Hallengren 的脚本以及来自其他站点的大量关于该主题的博客文章）。但是，我发现这些资源都没有提供用于维护全文索引的建议或脚本。

有Microsoft 文档提到对基表的 b 树索引进行碎片整理然后在全文目录上执行重组可能会提高性能，但它没有涉及任何更具体的建议。

我也发现了这个问题，但它主要关注更改跟踪（如何将底层表的数据更新传播到全文索引中），而不是可以最大化索引效率的定期维护的类型。

额外信息：基本性能测试

此SQL Fiddle包含的代码可用于创建带有AUTO更改跟踪的全文索引，并在修改表中的数据时检查索引的大小和查询性能。当我在生产数据的副本上运行脚本的逻辑（而不是小提琴中的人工制造数据）时，以下是我在每个数据修改步骤后看到的结果的摘要：

尽管此脚本中的更新语句相当人为，但这些数据似乎表明定期维护可以获得很多好处。

额外信息：初步想法

我正在考虑创建一个每晚或每周的任务。似乎此任务可以执行 REBUILD 或 REORGANIZE。

因为全文索引可能非常大（数千万或数亿行），所以我希望能够检测目录中的索引何时足够碎片化，从而需要进行 REBUILD/REORGANIZE。我有点不清楚什么启发式可能对此有意义。

我有一些自动生成的 T-SQL，这可能是有效的，但我不太明白。

ALTER TABLE [dbo].[MyTable]
WITH CHECK
CHECK CONSTRAINT [My_FORIEGN_KEY];

我知道什么是外键约束，但什么是外键约束CHECK CHECK？

已经有很多关于SQL Server中标量 UDF的危险的文章。随意搜索将返回大量结果。

不过，有些地方标量 UDF 是唯一的选择。

例如：处理 XML 时：XQuery 不能用作计算列定义。Microsoft 记录的一种选择是使用标量 UDF将 XQuery 封装在标量 UDF 中，然后在计算列中使用它。

这会产生各种影响和一些解决方法。

• 查询表时逐行执行
• 强制对表的所有查询串行运行

您可以通过对函数进行架构绑定来绕过逐行执行，并保留计算列或对其进行索引。即使未引用标量 UDF，这两种方法都不能阻止强制序列化查询表。

有没有一种已知的方法可以做到这一点？