我正在将数据库迁移到 Azure SQL 数据库。我阅读了有关 Azure SQL 数据库和 Azure 托管实例之间的差异，并注意到 Azure SQL 数据库不支持 CLR 函数。
这让我很惊讶，因为我已经将测试版数据库加载到 Azure SQL 数据库中，没有人抱怨出现问题。我查看了一下，果然，CLR 程序集就在那里，使用 CLR 函数运行查询工作正常。
因此我在网上搜索，看到的所有信息都是 CLR 不适用于 Azure SQL 数据库。但我在这里，Azure SQL 数据库中有一个可以运行的 CLR 程序集。
所以现在我想知道，我是否应该告诉企业我们必须改用托管实例，因为这是唯一支持 CLR 的地方？还是坚持使用 Azure SQL 数据库，因为它运行良好？还是我错过了什么？微软是否在没有告诉任何人的情况下重新启用了 CLR？
我有一个数据库，其名称中有括号。（别问！:-\）
它显示在 SSMS 中，但不显示在 Azure 中，因为它在创建时被取消了。它不显示在 Azure 中的数据库列表中。它显示在 SSMS 中，但无法通过右键单击删除。我想使用 SQL 删除它，但我不知道将括号作为数据库名称的字符（而不是转义符/分隔符）包含在语法中。
我尝试了以下方法，但无济于事：
删除数据库 [xxx_2024-07-24]
消息 911，级别 16，状态 1，第 1 行数据库“xxx_2024-07-24”不存在。请确保名称输入正确。
删除数据库 [[xxx_2024-07-24]]
消息 105，级别 15，状态 1，第 1 行 字符串 '[xxx_2024-07-24]' 后的引号未闭合。消息 102，级别 15，状态 1，第 1 行 '[xxx_2024-07-24]' 附近的语法不正确。
删除数据库 [[[xxx_2024-07-24]]]
消息 911，级别 16，状态 1，第 1 行数据库“[[xxx_2024-07-24]”不存在。请确保名称输入正确。
知道删除此数据库的正确语法吗？[xxx_2024-07-24]
（这更多的是一个文档问题，而不是行为问题。它已按照那里的建议从Stack overflow迁移过来。）
在研究另一个需要按原始元素顺序提取 XML 节点的问题的答案时，我遇到了几个答案（此处、此处和此处），它们使用了形式为的表达式ROW_NUMBER() OVER (ORDER BY xml.node)，并断言或暗示分配的行号值将按 XML 文档顺序分配。
但是，我找不到任何定义 行为的地方ORDER BY xml.node。尽管子句中似乎允许这样做OVER()，但文档并未具体提及 XML 节点。
例如，给定：
DECLARE @xml XML = '<root>
<node>One</node>
<node>Two</node>
<node>Three</node>
<node>Four</node>
</root>'
SELECT
ROW_NUMBER() OVER(ORDER BY xml.node) AS rn,
xml.node.value('./text()[1]', 'varchar(255)') AS value
FROM @xml.nodes('*/node') xml(node)
ORDER BY
ROW_NUMBER() OVER(ORDER BY xml.node)
返回结果如下：
rn | value
----------
1 | One
2 | Two
3 | Three
4 | Four
问题：文档中是否有任何地方保证这些结果？这是否被接受为有保证但未记录的行为？或者这是否是另一种情况，ORDER BY (SELECT NULL)对于看似预先排序的小型源数据集似乎有效，但最终在扩大规模时可能会失败？我之所以问这个问题，是因为我宁愿不推荐使用其行为和可靠性不受文档支持的技术。
有趣的是，尽管 XML 节点可以在 windowed 中使用ORDER BY，但在普通的 中却不允许SELECT ... ORDER BY。在普通的 select order-by 子句中使用时，ORDER BY xml.node会产生以下错误：
消息 493 级别 16 状态 1 第 7 行
从 nodes() 方法返回的列“node”不能直接使用。它只能与四种 XML 数据类型方法（exist()、nodes()、query() 和 value()）之一一起使用，或者在 IS NULL 和 IS NOT NULL 检查中使用。
上述错误消息没有列出窗口函数OVER(ORDER BY ...)作为允许的用途。
我的数据库中有以下表格。
CREATE TABLE [dbo].[LastNames](
[LastNameID] [int] IDENTITY(1,1) NOT NULL,
[LastName] [varchar](50) NOT NULL
) ON [PRIMARY]
GO
CREATE UNIQUE CLUSTERED INDEX [CIX_LastNames_LastName] ON [dbo].[LastNames]
(
[LastName] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
CREATE TABLE [dbo].[FirstNames](
[FirstNameID] [int] IDENTITY(1,1) NOT NULL,
[FirstName] [varchar](50) NOT NULL
) ON [PRIMARY]
GO
CREATE UNIQUE CLUSTERED INDEX [CIX_FirstNames_FirstName] ON [dbo].[FirstNames]
(
[FirstName] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
CREATE TABLE [dbo].[PersonsAnon](
[PersonID] [int] IDENTITY(1,1) NOT NULL,
[LastNameID] [int] NOT NULL,
[FirstNameID] [int] NOT NULL,
[Info1] [bit] NULL,
[Info2] [char](1) NULL,
[Info3] [nchar](50) NULL,
[AdressID] [int] NULL
) ON [PRIMARY]
GO
CREATE UNIQUE CLUSTERED INDEX [CIX_PersonsAnon_PersonID_LastNameID_FirstNameID] ON [dbo].[PersonsAnon]
(
[PersonID] ASC,
[LastNameID] ASC,
[FirstNameID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [NIX_PersonsAnon_LastNameID_FirstNameID] ON [dbo].[PersonsAnon]
(
[LastNameID] ASC,
[FirstNameID] ASC
)
INCLUDE([PersonID]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
对于那些拥有 AdventureWorks2014 数据库的人，我使用以下语句来填充表：
INSERT INTO dbo.LastNames (LastName) SELECT DISTINCT app.LastName FROM AdventureWorks2016.Person.Person AS app
INSERT INTO dbo.FirstNames (FirstName) SELECT DISTINCT app.FirstName FROM AdventureWorks2016.Person.Person AS app
INSERT INTO dbo.PersonsAnon (LastNameID, FirstNameID)
SELECT ln.LastNameID, fn.FirstNameID FROM LastNames ln CROSS APPLY FirstNames fn
使用以下语句来查看将创建什么样的执行计划：
SELECT pa.PersonID,
fn.FirstName,
ln.LastName,
pa.Info2
FROM PersonsAnon AS pa
JOIN LastNames AS ln
ON pa.LastNameID = ln.LastNameID
JOIN FirstNames AS fn
ON pa.FirstNameID = fn.FirstNameID
WHERE ln.LastName LIKE 'Pet%'
AND fn.FirstName LIKE 'John%'
ORDER BY
ln.LastName,
fn.FirstName;
为什么即使没有 JOIN 谓词，也要在 LastNames 和 FirstNames 之间执行 JOIN？是什么导致 QO JOIN 这两个表？
它看起来是这样的：
细节显示：
我一直认为CONCAT函数实际上是+（字符串连接）的包装，并带有一些额外的检查，以使我们的生活更轻松。
我还没有找到任何关于这些功能是如何实现的内部细节。至于性能，当数据在循环中连接时，调用似乎会产生开销CONCAT（这似乎很正常，因为有额外的 NULL 句柄）。
几天前，一位开发人员修改了一些字符串连接代码（从+到 ，CONCAT)因为不喜欢语法并告诉我它变得更快。
为了检查情况，我使用了以下代码：
DECLARE @V1 NVARCHAR(MAX)
,@V2 NVARCHAR(MAX)
,@V3 NVARCHAR(MAX);
DECLARE @R NVARCHAR(MAX);
SELECT @V1 = REPLICATE(CAST('V1' AS NVARCHAR(MAX)), 50000000)
,@V2 = REPLICATE(CAST('V2' AS NVARCHAR(MAX)), 50000000)
,@V3 = REPLICATE(CAST('V3' AS NVARCHAR(MAX)), 50000000);
这是变体一：
SELECT @R = CAST('' AS NVARCHAR(MAX)) + '{some small text}' + ISNULL(@V1, '{}') + ISNULL(@V2, '{}') + ISNULL(@V3, '{}');
SELECT LEN(@R); -- 1200000017
这是变体二：
SELECT @R = CONCAT('{some small text}',ISNULL(@V1, '{}'), ISNULL(@V2, '{}'), ISNULL(@V3, '{}'))
SELECT LEN(@R); -- 1200000017
对于较小的字符串，没有差异。在某些时候，CONCAT变体会变得更快：
我想知道有人可以分享一些内部结构或解释其行为，因为似乎可能存在一条规则，最好使用CONCAT.
版本：
Microsoft SQL Server 2022 (RTM-CU8) (KB5029666) - 16.0.4075.1 (X64) 2023 年 8 月 23 日 14:04:50 版权所有 (C) 2022 Windows Server 2019 Standard 10.0（内部版本 17763）上的 Microsoft Corporation 标准版（64 位） :)（管理程序）
确切的脚本如下所示：
DECLARE @V1 NVARCHAR(MAX)
,@V2 NVARCHAR(MAX)
,@V3 NVARCHAR(MAX);
DECLARE @R NVARCHAR(MAX);
SELECT @V1 = REPLICATE(CAST('V1' AS NVARCHAR(MAX)), 50000000)
,@V2 = REPLICATE(CAST('V2' AS NVARCHAR(MAX)), 50000000)
,@V3 = REPLICATE(CAST('V3' AS NVARCHAR(MAX)), 50000000);
--SELECT @R = CAST('' AS NVARCHAR(MAX)) + '{some small text}' + ISNULL(@V1, '{}') + ISNULL(@V2, '{}') + ISNULL(@V3, '{}'); -- 00:00:45 -- 00:01:22 -- 00:01:20
--SELECT LEN(@R); -- 300000017
SELECT @R = CONCAT('{some small text}',ISNULL(@V1, '{}'), ISNULL(@V2, '{}'), ISNULL(@V3, '{}')) -- 00:00:11 -- 00:00:16 -- 00:00:10
SELECT LEN(@R); -- 300000017
我正在更改 REPLICATE 函数的最后一个参数，以便为连接生成更大的字符串。然后，我将每个变体执行三次。
谁能解释下面的情况，其中两个看似相等的值没有减少DISTINCT？
上面的查询是SELECT DISTINCT name FROM master.sys.dm_os_spinlock_stats where name = 'SBS_UCS_DISPATCH';
等效方法SELECT name FROM master.sys.dm_os_spinlock_stats where name = 'SBS_UCS_DISPATCH' GROUP BY name;也执行相同的操作，并且添加HAVING COUNT(1) > 1不会产生行。
@@VERSION是Microsoft SQL Server 2019 (RTM-CU13) (KB5005679) - 15.0.4178.1 (X64) 2021 年 9 月 23 日 16:47:49 版权所有 (C) 2019 Microsoft Corporation 企业版：Windows Server 上基于核心的许可（64 位） 2016 标准 10.0（内部版本 14393：）
您有一个接受日期时间数组的存储过程，这些数组被加载到临时表中，并用于过滤表中的日期时间列。
编写查询来执行过滤的最有效方法是什么？
USE StackOverflow2013;
CREATE TABLE
#d
(
dfrom datetime,
dto datetime,
PRIMARY KEY (dfrom, dto)
)
INSERT
#d
(
dfrom,
dto
)
SELECT
dfrom = '2013-11-20',
dto = '2013-12-05'
UNION ALL
SELECT
dfrom = '2013-11-27',
dto = '2013-12-12';
CREATE INDEX
p
ON dbo.Posts
(CreationDate)
WITH
(SORT_IN_TEMPDB = ON, DATA_COMPRESSION = PAGE);
我能得到的最好的就是EXISTS像这样使用：
SELECT
c = COUNT_BIG(*)
FROM dbo.Posts AS p
WHERE EXISTS
(
SELECT
1/0
FROM #d AS d
WHERE p.CreationDate BETWEEN d.dfrom
AND d.dto
);
这导致了一个看起来相当悲伤的执行计划：
嵌套循环是唯一可用的连接运算符，因为我们没有相等谓词。
我正在寻找的是产生不同类型连接的替代语法。
谢谢！
有什么方法可以从触发器内部判断，当它被触发时，它是由于另一个特定触发器中发生的 DML 操作而被触发的？
有没有机会在函数中公开有关调用堆栈的任何信息EVENTDATA()？还是其他功能？我宁愿不必粉碎 XML。?
我的理想目标是从第二个触发器的范围内获取执行导致第二个触发器触发的 DML 的原始触发器的名称。但我也对类似的识别来源的方式持开放态度。
我可以完全控制所讨论的两个触发器的代码。
我正在研究SQL Server 2019。
我有一张表dbo.AllDates，其中包含从1990到2050的所有日期。我有另一个表dbo.ActualExchangeRates，其中我有在给定来源中找到汇率的日期的某些货币的实际汇率。
我正在尝试编写查询以获取2010和2020之间所有日期的所有货币。如果找到速率，则写入速率，否则写入NULL。
鉴于这种情况和下面给出的代码，有人可以帮我理解为什么SELECT查询没有生成任何结果，甚至看不到估计的执行计划吗？
CREATE TABLE dbo.AllDates(Date date)
CREATE TABLE dbo.ActualExchangeRates(Date date, Currency char(3), Rate real)
--Query 1: Not generating any results or estimated plan
SELECT d.Date, m.Currency, c.Rate
FROM dbo.AllDates d
INNER JOIN (
select
currency,
'20100101' as mindate,
'20201231' as maxdate
from dbo.ActualExchangeRates
group by currency
) as m on d.date between m.mindate and m.maxdate
LEFT JOIN dbo.ActualExchangeRates C ON C.Currency = m.Currency and c.Date = d.Date;
查询针对空表运行 9 分钟后出现以下错误：
消息 701，级别 17，状态 123，第 5 行
资源池“默认”中的系统内存不足，无法运行此查询。
似乎这取决于 SQL Server 在出现错误之前有多少内存可用。对我来说，鉴于表中没有数据，这看起来像是 SQL 引擎中的错误。
现在，我知道上面的查询可以用许多不同的方式编写，其他方式也可以生成结果，但我的问题是，即使两个表都是空的，为什么 SQL Server 在该查询上永远挂起？
我在 Azure SQL 实例 (12.0.2000.8) 中有一个表，当我查询它时发现了这种奇怪的行为。
该列被定义为整数，但它不响应“WHERE”过滤器，也转换为 varchar 返回奇怪的结果。它只发生在一张表中（到目前为止）。
这里发生了什么？是错误吗？难道我做错了什么？我应该删除表并重新创建它吗？
更多信息：当我查询表时出现问题。如果我使用不同的机器和客户端，我会遇到同样的问题（它也发生在 JDBC 上）。
排序规则是 SQL_Latin1_General_CP1_CI_AS
谢谢！
当使用包含一组已定义列的 SELECT 语句查询数据库时，大约 21 秒内会收到结果。
, *如果在定义的列集列表末尾有一个额外的星号 ( )，则查询将在 2 秒内返回结果。
执行计划有很大不同。
您可以使用 PasteThePlan 中的链接找到好的实际查询执行计划和坏的实际查询执行计划。
SELECT -- DISTINCT -- 27.04.2020
'SchuelerKlasse' AS EcoQuery,
VX_PERSON.PER_MAN_ID, VX_PERSON.PER_ID, VX_PERSON.PER_NAME, VX_PERSON.PER_VORNAME, VX_PERSON.PER_LB_PER_ID,
VX_PERSON.PER_GESCHLECHT, VX_PERSON.PER_GEBURTSDATUM, VX_PERSON.PER_TELP, VX_PERSON.PER_MAILP, VX_PERSON.PER_NATP, VX_PERSON.PER_VERSICHERTENNUMMER, VX_PERSON.PER_LAND,
VX_ADRESSE.ADR_STRASSE, VX_ADRESSE.ADR_PLZ, VX_ADRESSE.ADR_ORT,
VX_KLASSE.KL_CODE, VX_KLASSE.KL_BEZEICHNUNG,
VX_KLASSEABSCHNITTSCHUELER.KAS_ANMELDE_STATUS,
VX_KLASSEABSCHNITTSCHUELER.KAS_ANMELDETYP, VX_KLASSEABSCHNITTSCHUELER.KAS_ABSCHNITTSNR,
VX_KLASSE_ZEITRAUM.KLZ_IS_ABSCHLUSSKLASSE, VX_KLASSE_ZEITRAUM.KLZ_ZR_NR,
VX_ZEITRAUM.ZR_BEGINN, VX_ZEITRAUM.ZR_ENDE
,'' AS FA_CODE
,'' AS FA_BEZ_STP, '' AS FA_BEZ_STP_LANG
, '' AS EcoOrig_FA_CODE, '' AS EcoOrig_FA_BEZ_STP, '' AS EcoOrig_FA_BEZ_STP_LANG
, VX_ANGEBOT.ANG_BEGINN
,*
FROM
ECOLST.VX_KLASSE_ZEITRAUM,
ECOLST.VX_PERSON,
ECOLST.VX_KLASSE,
ECOLST.VX_KLASSEABSCHNITTSCHUELER,
ECOLST.VX_ZEITRAUM,
ECOLST.VX_ADRESSE
, ECOSYS.T_KLASSE
, ECOLST.VX_ANGEBOT
WHERE
VX_KLASSE_ZEITRAUM.klz_kl_id = VX_KLASSE.kl_id
AND VX_KLASSE_ZEITRAUM.klz_zr_id = VX_ZEITRAUM.zr_id
AND VX_KLASSEABSCHNITTSCHUELER.kas_ang_id = VX_KLASSE.kl_ang_id
AND VX_KLASSEABSCHNITTSCHUELER.kas_zr_id = VX_ZEITRAUM.zr_id
AND VX_KLASSEABSCHNITTSCHUELER.kas_per_id = VX_PERSON.per_id
AND VX_KLASSEABSCHNITTSCHUELER.kas_kl_id = VX_KLASSE.kl_id
AND VX_KLASSEABSCHNITTSCHUELER.KAS_ANMELDE_STATUS LIKE 'De%' -- LIKE 'Definitiv%'
AND VX_PERSON.per_id = VX_ADRESSE.adr_per_id
AND VX_PERSON.per_man_id = VX_KLASSE.kl_man_id
AND VX_KLASSE.KL_ANG_ID = VX_ANGEBOT.ANG_ID
AND VX_KLASSE.KL_MAN_ID = 15
AND VX_KLASSE.KL_ID = T_KLASSE.KL_ID
AND T_KLASSE.KL_STATUS_ID = 491 -- d.h. TS_CODE.CODE_UP_BEZEICHNUNG = 'AKTIV'
AND VX_KLASSE.KL_KLASSENTYP_ID IN (742,743,1235,1926,2075,2076,2078,2079,2080,2081,2086,2103,2118,2119,2122,2152,2252,2308,2416)
AND VX_PERSON.PER_NP = 1 -- Natürliche Person
AND LEN(LTRIM(RTRIM(VX_PERSON.PER_VORNAME))) > 0 -- TRIM() kann erst ab SQL Server 2017 verwendet werden
AND LEN(LTRIM(RTRIM(VX_PERSON.PER_NAME))) > 0 -- TRIM() kann erst ab SQL Server 2017 verwendet werden
AND VX_ZEITRAUM.zr_beginn <= CONVERT(DATETIME, '20.05.2023', 104)
AND VX_ZEITRAUM.zr_ende >= CONVERT(DATETIME, '14.02.2023', 104)
AND VX_PERSON.per_man_id IN ( 15 )
--AND VX_Person.PER_ID IN (233777,233779)
*一般建议在定义列列表时不要使用，但在我的例子中，, *在末尾添加到列列表，可以显着加快查询速度。（从 21 秒减少到 2 秒）
实际执行计划中没有缺失索引建议。
, *我认为这与在语句中使用时返回的特定列有关，这些列可能包含在查询优化器认为有用的索引中，但我不确定如何查明这些列。
为了说服 SQL Server 运行不包含, *列列表的执行不佳的语句，使用与包含列列表中的附加项的性能语句类似的计划，我必须创建哪些索引？, *
我是否必须分析良好执行计划中使用的所有索引并创建缩减索引（省略某些列）以便查询优化器考虑对语句使用类似的良好, *执行计划而不需要额外的？
OPTION (MIN_GRANT_PERCENT = 10, MAX_GRANT_PERCENT = 15)
应用上述解决方案仅提供了大约 1 小时的临时性能提升。之后查询恢复到错误的执行计划。我不知道为什么...
数据库兼容级别
,*使用以下命令将数据库的兼容级别向下更改为 110 (SQL Server 2012)，导致上述查询的性能不断提高，而无需在列列表中添加。
USE [master]
GO
ALTER DATABASE [ECOWEBBSP] SET COMPATIBILITY_LEVEL = 110
GO
兼容级别为 110 的查询执行计划表明，查询优化器在检索数据时选择了一种完全不同的方法，并且在分配正确的内存量 (110 MB) 方面没有任何问题。
将兼容级别设置为 110 是我唯一的选择吗？
Erik 的回答中提到的Ominous Function是由视图中的fi_kla_is_abschlussklasse列触发的。基础表在检索数据时调用标量值函数。该函数本身返回 0 或 1，具体取决于学生是在毕业班 (1) 还是不在毕业班 (0)。VX_KLASSE_ZEITRAUM.KLZ_IS_ABSCHLUSSKLASSEECOLST.VX_KLASSE_ZEITRAUM
但是，在兼容级别设置为 110 (SQL Server 2012) 的情况下运行时，该函数似乎对查询持续时间的影响不大。有关详细信息，请参阅兼容级别为 110 的查询执行计划。
tl; dr - 如标题所述 - 如果我禁用表上的非聚集索引，是否仍使用该索引的链接统计信息？
我知道有很多关于“删除与禁用索引”的问题......但我找不到专门涵盖统计信息的问题。
我知道统计数据没有改变或改变（至少这是我从 MS 文档中收集到的）。但我的问题是统计数据是否仍在使用。
作为背景，我正在从事一个大型索引调优项目。它涉及在数百个具有不同工作负载模式的相同数据库中添加/删除索引。总共有超过 200 万个索引。
我的第一步是删除所有“未使用”的索引。但是，我没有放弃它们，而是考虑禁用它们以保留定义。这将允许我在表中记录任何禁用的索引的实例、数据库、对象 ID 和索引名称/ID。如果之后性能开始下降，可以重新启用（重建）索引。
但是，如果已禁用索引的统计信息仍用于生成计划...那么禁用它们不会产生与删除它们相同的性能影响。如果是这种情况，那么禁用索引就不是“真正的”性能影响测试，如果禁用的索引最终被删除，我就有引入性能问题的风险。
我的 SQL Server 版本是 SQL Server 2019 (RTM-CU18)。以下重现代码需要创建一个内存文件组。对于后续的任何人，请记住内存中的文件组一旦创建就不能从数据库中删除。
我有一个简单的内存表，我在其中插入 1 - 1200 之间的整数：
DROP TABLE IF EXISTS [dbo].[InMem];
CREATE TABLE [dbo].[InMem] (
i [int] NOT NULL,
CONSTRAINT [PK_InMem] PRIMARY KEY NONCLUSTERED (i ASC)
) WITH ( MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_ONLY );
INSERT INTO [dbo].[InMem]
SELECT TOP (1200) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;
我还有以下本机编译的存储过程：
GO
CREATE OR ALTER PROCEDURE p1
WITH NATIVE_COMPILATION, SCHEMABINDING
AS
BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'us_english')
SELECT c1.i, c2.i, c3.i
FROM dbo.[InMem] c1
CROSS JOIN dbo.[InMem] c2
CROSS JOIN dbo.[InMem] c3
WHERE c1.i + c2.i + c3.i = 3600;
END;
GO
该过程在执行时返回一行。在我的机器上大约需要 32 秒才能完成。在执行时，我无法观察到内存使用方面的任何异常行为。
我可以创建一个类似的表类型：
CREATE TYPE [dbo].[InMemType] AS TABLE(
i [int] NOT NULL,
INDEX [ix_WordBitMap] NONCLUSTERED (i ASC)
) WITH ( MEMORY_OPTIMIZED = ON );
以及相同的存储过程，但改用表类型：
GO
CREATE OR ALTER PROCEDURE p2 (@t dbo.[InMemType] READONLY)
WITH NATIVE_COMPILATION, SCHEMABINDING
AS
BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'us_english')
SELECT c1.i, c2.i, c3.i
FROM @t c1
CROSS JOIN @t c2
CROSS JOIN @t c3
WHERE c1.i + c2.i + c3.i = 3600;
END;
GO
新存储过程在大约一分钟后抛出错误：
消息 701，级别 17，状态 154，过程 p2，第 6 行 [批处理起始行 57] 资源池“默认”中的系统内存不足，无法运行此查询。
sys.dm_os_memory_clerks当程序执行时，我可以通过查询dmv看到 MEMORYCLERK_XTP 内存管理员使用的内存量增加到数据库的大约 2800 MB 。根据sys.dm_db_xtp_memory_consumersDMV，几乎所有的内存使用似乎都来自“64K 页面池”消费者：
作为参考，这里是我如何执行新存储过程的。它使用与表相同的 1200 行：
DECLARE @t dbo.[InMemType];
INSERT INTO @t (i)
SELECT i
from [dbo].[InMem];
EXEC p2 @t;
生成的查询计划是一个没有阻塞运算符的简单嵌套循环计划。根据请求，这是第二个存储过程的估计查询计划。
我不明白为什么当我使用表值参数时，这样的查询的内存使用量会增长到超过 2 GB。我已经阅读了各种文档和内存中 OLTP 白皮书，但找不到任何关于此行为的参考。
使用 ETW 跟踪，我可以看到第一个过程将其大部分 cpu 时间用于调用hkengine!HkCursorHeapGetNext，而第二个过程将其大部分 cpu 时间用于调用hkengine!HkCursorRangeGetNext. 我还可以获得这两个程序的 C 源代码。第一个程序在这里，第二个程序有内存问题，在这里。但是，我不知道如何阅读 C 代码，所以我不知道如何进一步调查。
为什么在对表值参数执行嵌套循环时，一个简单的本机编译存储过程会使用超过 2 GB 的内存？当我在存储过程之外运行查询时，也会出现此问题。
我在 AWS i3.16xlarge 上运行 SQL Server 2022 RC1 设置，具有 2 个套接字、2 个 NUMA 节点、每个节点 32 个逻辑处理器、总共 64 个逻辑处理器。
安装程序推荐 MAXDOP 8：
但是，如果您单击该链接来配置 MAXDOP，建议会说：
根据那篇知识库文章，MAXDOP 应该是 16，而不是 8。当然，从技术上讲，8 小于 16 - 但 2、4 或 15 也是如此。8 来自哪里？
SQL Server 安装完成并启动服务后，日志显示 SQL Server 正在自动实现具有 4 个节点的 Soft-NUMA，每个节点具有 16 个逻辑处理器：
同样，这表明 MAXDOP 应该是 16。
这是一个错误，还是我错过了一些明显的东西？设置将在 MAXDOP 8 停止的地方是否还有其他不成文的规则？
SQL Server 2016 添加了AT TIME ZONE运算符。从文档中：
AT TIME ZONE 实现依赖于 Windows 机制来跨时区转换日期时间值。
AT TIME ZONEmscorlib.ni!TimeZoneInfo.ConvertTime根据针对简单查询的 ETW 跟踪调用该方法。Jonathan Kehayias 有一篇博文，他从System.TimeZoneInfo课堂上提取了所有时区规则。我只能在输出中找到 2004 年 1 月 1 日或以后生效的规则：
Rob Farley 在一篇博文中提到，2000 年的时区规则更改似乎没有得到遵守AT TIME ZONE：
它通过使用包含所有信息的 Windows 注册表工作，但遗憾的是，当回顾过去时，它并不完美。澳大利亚在 2008 年更改了日期，美国在 2005 年更改了日期——这两个国家在一年中的大部分时间都在节约日光。AT TIME ZONE 明白这一点。但似乎并没有意识到，在 2000 年的澳大利亚，由于悉尼奥运会，澳大利亚在大约两个月前开始实行夏令时。
我觉得有大量间接证据表明，AT TIME ZONE操作员可能会为早于 2004 年的日期返回不准确的结果。但是，我找不到任何AT TIME ZONE使用System.TimeZoneInfo该类的文档，AT TIME ZONE对于较早的日期可能不准确，或者System.TimeZoneInfo该类对于较早的日期可能不准确。
AT TIME ZONE是否存在导致 2004 年之前返回不准确结果的 SQL Server 产品限制？
我有一个表，其中包含一个记录 ID、一个组 ID（将 1 个或多个记录链接到一个组中）和每个记录的哈希值。
CREATE TABLE HashTable(
RecordID VARCHAR(255),
GroupIdentifier VARCHAR(255),
Hash VARCHAR (255),
GroupHashList VARCHAR(4000)
)
（我知道这不是一个高效的表，但对于本示例而言，它只是一个临时表）。
我想为每个组生成一个哈希，所以我认为最简单的方法是连接组中每个记录的哈希。RecordID 是唯一的，但这些记录相关的内容不一定是唯一的，因此哈希可能是重复的。这样做的目的是标记完全重复的组，即一个组是该组中的所有记录都是另一个组中所有记录的重复。如果要将组的所有成员识别为重复组，则 GUI 需要组的所有成员具有相同的哈希值。
我正在使用 STRING_AGG 连接组中记录的各个散列，并按散列对它们进行排序，以确保我得到重复组的相同字符串。我实际上并不关心哈希的顺序是什么，只要每次都相同。当我将它作为 SELECT 查询运行时，它工作正常，我可以看到重复组的相同字符串。当我采用相同的 SELECT 查询并将其放入 UPDATE 查询时，排序似乎丢失了。
SELECT STRING_AGG([Hash],';') WITHIN GROUP (ORDER BY [Hash] ASC)
FROM HashTable
GROUP BY [GroupIdentifier]
这给出了结果（例如一对重复组）：
73F294873462B2BA0E930FD16DCCB7;90E749375DF806CB6E3F5CA48FFA38;E44256CE7CFCB971EB679BAC25A697
73F294873462B2BA0E930FD16DCCB7;90E749375DF806CB6E3F5CA48FFA38;E44256CE7CFCB971EB679BAC25A697
当我将相同的代码放入 UPDATE 查询时，它没有正确排序它们：
UPDATE HashTable
SET GroupHashList = c.HashList
FROM HashTable
INNER JOIN (
SELECT (STRING_AGG([Hash],';') WITHIN GROUP (ORDER BY [Hash] ASC)) AS [HashList],
[GroupIdentifier]
FROM HashTable
GROUP BY [GroupIdentifier]) c
ON c.[GroupIdentifier] = HashTable.[GroupIdentifier]
写入表的相同两组的结果：
73F294873462B2BA0E930FD16DCCB7;90E749375DF806CB6E3F5CA48FFA38;E44256CE7CFCB971EB679BAC25A697
73F294873462B2BA0E930FD16DCCB7;E44256CE7CFCB971EB679BAC25A697;90E749375DF806CB6E3F5CA48FFA38
我错过了什么？
我第一次得到的是
Hash1; Hash2; Hash3
Hash1; Hash2; Hash3
但是当它在 UPDATE 查询中时，我得到
Hash1; Hash2; Hash3
Hash1; Hash3; Hash2
更新查询是按记录 ID 排序的，虽然不知道是不是巧合。（https://dbfiddle.uk/CPG1-z2l）
我刚刚了解到可以在表上禁用索引。甚至可以禁用聚集索引。之后，如果聚集索引，用户将无法访问索引或数据。我们什么时候禁用索引？我只是不明白用例。
我再次发现 SQL Server 和 MERGE 语句存在问题，需要一些确认。
我可以在 Azure 数据库上不断重现我的问题（但不能在本地 SQL Server 2017/2019 上）。
请执行以下步骤（一步一步，而不是一个命令执行）！
1) 架构脚本：
CREATE TABLE [dbo].[ImpactValueHistory]
(
[Rn] BIGINT NOT NULL,
[ImpactId] UNIQUEIDENTIFIER NOT NULL,
[ImpactValueTypeId] INT NOT NULL,
[Date] DATE NOT NULL,
[Value] DECIMAL(38, 10) NOT NULL,
[ValidFrom] DATETIME2 NOT NULL CONSTRAINT [DF_ImpactValueHistory_ValidFrom] DEFAULT CONVERT(DATETIME2, '0001-01-01'),
[ValidTo] DATETIME2 NOT NULL CONSTRAINT [DF_ImpactValueHistory_ValidTo] DEFAULT CONVERT(DATETIME2, '9999-12-31 23:59:59.9999999'),
[ImpactPeriodId] INT NOT NULL,
[NormalizedValue] DECIMAL(38, 10) NOT NULL,
)
GO
CREATE CLUSTERED COLUMNSTORE INDEX [COLIX_ImpactValueHistory]
ON [dbo].[ImpactValueHistory];
GO
CREATE NONCLUSTERED INDEX [IX_ImpactValueHistory_ValidFrom_ValidTo_ImpactId_DimensionItemId]
ON [dbo].[ImpactValueHistory] ([ValidFrom], [ValidTo], [ImpactId], [ImpactValueTypeId], [Date]);
GO
CREATE TABLE [dbo].[ImpactValue]
(
[Rn] BIGINT NOT NULL IDENTITY(1,1),
[ImpactId] UNIQUEIDENTIFIER NOT NULL,
[ImpactValueTypeId] INT NOT NULL,
[Date] DATE NOT NULL,
[Value] DECIMAL(38, 10) NOT NULL,
[ValidFrom] DATETIME2 GENERATED ALWAYS AS ROW START NOT NULL CONSTRAINT [DF_ImpactValue_ValidFrom] DEFAULT CONVERT(DATETIME2, '0001-01-01'),
[ValidTo] DATETIME2 GENERATED ALWAYS AS ROW END NOT NULL CONSTRAINT [DF_ImpactValue_ValidTo] DEFAULT CONVERT(DATETIME2, '9999-12-31 23:59:59.9999999'),
[ImpactPeriodId] INT NOT NULL,
[NormalizedValue] DECIMAL(38, 10) NOT NULL,
PERIOD FOR SYSTEM_TIME ([ValidFrom], [ValidTo]),
CONSTRAINT [PK_ImpactValue] PRIMARY KEY NONCLUSTERED ([ImpactId], [ImpactValueTypeId], [Date], [ImpactPeriodId])
)
WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = [dbo].[ImpactValueHistory]))
GO
CREATE UNIQUE CLUSTERED INDEX [IX_ImpactValue_Id] ON [dbo].[ImpactValue]([Rn])
GO
CREATE COLUMNSTORE INDEX [CIX_ImpactValue] ON [dbo].[ImpactValue] ([ImpactId], [ImpactValueTypeId], [Date], [Value], [NormalizedValue])
GO
2) 插入一些随机数据的脚本
DECLARE @inserted0 TABLE ([Date] DATE, [ImpactId] uniqueidentifier, [ImpactPeriodId] int, [ImpactValueTypeId] int);
MERGE [dbo].[ImpactValue] USING (
SELECT TOP 278 -- <-- this number is critical
DATEADD(MONTH, ROW_NUMBER() OVER(ORDER BY [Name]) - 1, '2000-01-01') AS [Date],
NEWID() AS [ImpactId],
1 AS [ImpactPeriodId],
1 AS [ImpactValueTypeId],
99 AS [Value],
99 AS [NormalizedValue]
FROM [sys].[all_columns]
) AS i ([Date], [ImpactId], [ImpactPeriodId], [ImpactValueTypeId], [Value], [NormalizedValue]) ON 1=0
WHEN NOT MATCHED THEN
INSERT ([Date], [ImpactId], [ImpactPeriodId], [ImpactValueTypeId], [Value], [NormalizedValue])
VALUES (i.[Date], i.[ImpactId], i.[ImpactPeriodId], i.[ImpactValueTypeId], i.[Value], i.[NormalizedValue])
OUTPUT INSERTED.[Date], INSERTED.[ImpactId], INSERTED.[ImpactPeriodId], INSERTED.[ImpactValueTypeId]
INTO @inserted0;
SELECT * FROM @inserted0
这一步应该返回所有插入的行！
3）从步骤2中删除数据） 这一步正在填充配置的历史表
DELETE [dbo].[ImpactValue]
4）再次插入一些随机数据 您可以使用步骤2中的脚本）
我必须注意，步骤 1) - 4) 应该单独执行，而不是在GO.
这一步应该再次返回所有插入的行！但事实并非如此！ 在我这边，我总是得到一个空的结果。这可以在我们的三个生产数据库上重现:(
MERGE 语句由 EF Core 生成，目前我正在通过设置 Max Batch Size 来解决此问题。但这不可能是最终的解决方案。
它必须与在时态表上配置了非聚集索引的时态表有关。
也可以看看：
在过去，我已经偶然发现了这个问题：
但是我当前的问题只能在 Azure SQL 数据库上重现，并且不会引发任何错误。
有趣的旁注：
如果没有历史表上的 COLUMNSTORE 索引，它就可以工作。通过仅删除主表上的 COLUMNSTORE 索引，我看到了同样的问题。
TOP 278(a) 重现问题和 (b) 不重现的情况的实际执行计划TOP (@BatchSize)可在https://1drv.ms/u/s!AsOa6e9ukBWQlIRg9_9eySDFp5hvEA?e=KBQBsP获得。我还添加了批量大小为 277 的实际执行计划。两者都使用这个大小！
针对勒索软件的最佳保护之一是将所有数据库文件备份到一个完全独立的系统。我们已经做到了。
但一种想法是数据库的备份现在可能包含勒索软件。这可能吗？这是 2016 SQL Server 本机创建的 .bak。还是勒索软件不可能将自己嵌入到备份文件中？
我正在寻找一个通用术语，例如数据库抽象，它包括所有表格数据结构，如数据库表、视图、表格查询结果等。
据我了解，“实体”不是正确的术语，因为它对应于表而不是视图甚至查询。“结果”在可修改的数据结构上是违反直觉的。
在专业环境中，哪个是合适的术语？