Heinzi's questions

在查询特定表的元数据时，我可以

1. 使用该OBJECT_ID功能或
2. 加入相关的系统表（sys.tables和sys.schemas）。

例如，这两个查询都将返回 table 的所有 DML 触发器myTable：

SELECT *
  FROM sys.triggers AS t
 WHERE t.parent_id = OBJECT_ID('[dbo].[myTable]', 'U')

SELECT *
  FROM sys.triggers AS tr
       INNER JOIN sys.tables AS tab ON tr.parent_id = tab.object_id 
       INNER JOIN sys.schemas AS s ON tab.schema_id = s.schema_id 
 WHERE s.name = 'dbo' AND tab.name = 'myTable';

纯粹是口味问题，还是有充分的理由偏爱其中一个（如果两者都能解决您的问题）？

我的初步分析是：

• 选项 1 更短（显然）。
• 使用选项 2，我无需担心引用/转义表/模式名称（如果它包含特殊字符）。
• 查询计划不同（但不太可能产生巨大差异，因为这不是我计划经常执行的操作）。

我错过了什么重要的事情吗？

[更新：此问题描述了已在SQL Server 2019 的累积更新 5 中修复的错误。]

考虑以下复制示例（小提琴）：

CREATE FUNCTION dbo.Repro (@myYear int)
RETURNS datetime
AS
BEGIN
    IF @myYear <> 1990
    BEGIN
        RETURN NULL
    END

    DECLARE @firstOfYear datetime;
    SET @firstOfYear = DATEFROMPARTS(@myYear, 1, 1);
    
    IF DATEDIFF(day, @firstOfYear, @firstOfYear) <> 0
    BEGIN
        RETURN NULL
    END

    RETURN @firstOfYear
END
SELECT dbo.Repro(0);

显然，如果输入为1990，则该函数应返回 1990 年 1 月的第一天，NULL否则返回。是的，我知道这DATEDIFF(day, @firstOfYear, @firstOfYear) <> 0是一个荒谬的操作。这是一个演示潜在错误的mcve ，而不是生产代码。

现在让我们SELECT dbo.Repro(0)在 SQL Server 2017 和 SQL Server 2019 上执行。

预期结果：NULL。

SQL Server 2017 上的实际结果：NULL

SQL Server 2019 上的实际结果：

消息 289 级别 16 状态 1 行 1
无法构造数据类型日期，某些参数的值无效。

显然，SQL Server 2019 会执行初始保护子句 ( IF @myYear <> 1990) 下面的一些代码，即使它不应该执行。

我的问题：

• 这是预期的行为，还是我在 SQL Server 2019 中发现了错误？
• 如果这是预期的行为，我该如何正确编写验证输入参数的保护子句？

让我说一个明显的拳头：我完全理解浮点类型不能准确地表示十进制值。这不是那个！然而，浮点计算应该是确定性的。

既然这已经不碍事了，让我向您展示我今天观察到的奇怪案例。我有一个浮点值列表，我想总结一下：

CREATE TABLE #someFloats (val float);
INSERT INTO #someFloats (val) VALUES (1), (1), (1.2), (1.2), (1.2), (3), (5);

SELECT STR(SUM(#someFloats.val), 30, 15) FROM #someFloats;

DROP TABLE #someFloats;

-- yields:
--   13.600000000000001

到目前为止，一切都很好 - 这里没有惊喜。我们都知道1.2不能用二进制表示精确地表示，所以“不精确”的结果是意料之中的。

现在，当我左加入另一个表时，会发生以下奇怪的事情：

CREATE TABLE #A (a int);
INSERT INTO #A (a) VALUES (1), (2);

CREATE TABLE #someFloats (val float);
INSERT INTO #someFloats (val) VALUES (1), (1), (1.2), (1.2), (1.2), (3), (5);

SELECT #A.a, STR(SUM(#someFloats.val), 30, 15)
  FROM #someFloats LEFT JOIN #A ON 1 = 1
 GROUP BY #A.a;

DROP TABLE #someFloats;
DROP TABLE #A;

-- yields
--   1   13.600000000000001
--   2   13.599999999999998

_{（sql fiddle，你也可以在那里看到执行计划）}

我对相同的值有相同的总和，但浮点错误不同。如果我向 table 添加更多行，我们可以看到该值在这两个值之间交替。我只能用;重现这个问题。在这里按预期工作。#ALEFT JOININNER JOIN

这很不方便，因为这意味着 a DISTINCT, GROUP BYorPIVOT将它们视为不同的值（这实际上是我们发现这个问题的方式）。

显而易见的解决方案是对值进行舍入，但我很好奇：这种行为是否有合乎逻辑的解释？

我们有运行 SQL Server（2008 SP4 和 2016 SP1）的 PC，它们经常断电。显然，这有时会导致 SQL Server 数据库（索引）损坏，我们需要在之后进行恢复。

我知道 SQL Server 不是为这种情况而设计的，正确的解决方案是解决掉电的原因（如果您好奇，请参阅下文）。尽管如此，我可以设置 SQL Server 中的任何调整选项来降低断电时数据库损坏的风险吗？

背景：“PC”是安装在叉车上的 Windows 平板电脑。当用户关闭叉车时，平板电脑就会断电。我们曾尝试教用户在关闭叉车之前正确关闭 Windows，但失败了（可能是因为大多数时候只是将其关闭“有效”）。我们目前还在研究其他选项，例如添加一个 UPS，该 UPS 会向平板电脑发出信号以在断电时关闭。

我们在 SQL Server 中遇到了一个有趣的问题。考虑以下重现示例：

CREATE TABLE #test (s_guid uniqueidentifier PRIMARY KEY);
INSERT INTO #test (s_guid) VALUES ('7E28EFF8-A80A-45E4-BFE0-C13989D69618');

SELECT s_guid FROM #test
WHERE s_guid = '7E28EFF8-A80A-45E4-BFE0-C13989D69618'
  AND s_guid <> NEWID();

DROP TABLE #test;

小提琴

请暂时忘记s_guid <> NEWID()条件似乎完全没用——这只是一个最小的重现示例。由于NEWID()匹配某个给定常量值的概率极小，因此每次都应评估为 TRUE。

但事实并非如此。运行此查询通常返回 1 行，但有时（非常频繁，10 次中超过 1 次）返回 0 行。我已经在我的系统上使用 SQL Server 2008 复制了它，您可以使用上面链接的小提琴（SQL Server 2014）在线复制它。

查看执行计划表明查询分析器显然将条件拆分为s_guid < NEWID() OR s_guid > NEWID()：

...这完全解释了为什么它有时会失败（如果第一个生成的 ID 小于给定的 ID 而第二个大于给定的 ID）。

是否允许 SQL Server 计算A <> B为A < B OR A > B，即使其中一个表达式是不确定的？如果是，它记录在哪里？还是我们发现了错误？

有趣的是，AND NOT (s_guid = NEWID())产生相同的执行计划（和相同的随机结果）。

当开发人员想要有选择地排除特定行并使用时，我们发现了这个问题：

s_guid <> ISNULL(@someParameter, NEWID())

作为“捷径”：

(@someParameter IS NULL OR s_guid <> @someParameter)

我正在寻找文档和/或错误确认。该代码并不是所有相关的，因此不需要解决方法。

如果我直接在 SQL Server Management Studio 中执行我的（简单）查询...

SELECT auftrag_prod_soll.ID 
  FROM auftrag_prod_soll 
 WHERE auftrag_prod_soll.auftrag_produktion = 51621 
   AND auftrag_prod_soll.prod_soll_über = 539363
 ORDER BY auftrag_prod_soll.reihenfolge

...一切都很好，很快...

Table 'auftrag_prod_soll'. Scan count 2, logical reads 6, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
  CPU time = 0 ms,  elapsed time = 102 ms.

...因为 SQL Server 根据两个过滤条件选择一个合理的执行计划：

另一方面，如果我的应用程序使用游标执行相同的查询...

declare @p1 int
declare @p3 int
set @p3=4
declare @p4 int
set @p4=1
declare @p5 int
set @p5=-1
exec sp_cursoropen @p1 output,N' SELECT auftrag_prod_soll.ID  FROM auftrag_prod_soll  WHERE auftrag_prod_soll.auftrag_produktion =  51621   AND auftrag_prod_soll.prod_soll_über =  539363 ORDER BY auftrag_prod_soll.reihenfolge',@p3 output,@p4 output,@p5 output

exec sp_cursorfetch @p1,2,0,1

exec sp_cursorclose @p1

……演技太差了……

Table 'auftrag_prod_soll'. Scan count 1, logical reads 1118354, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
  CPU time = 1094 ms,  elapsed time = 1231 ms.

...因为 SQL Server 选择了一个糟糕的执行计划：

我知道我可以通过使用索引提示来解决这个问题。但是，我想了解为什么会这样。

我努力了：

• DBCC FREEPROCCACHE
• UPDATE STATISTICS auftrag_prod_soll

但这并没有什么不同。

我还查看了 prod_soll_über 和 auftrag_produktion 上两个索引的直方图：它们分布良好，因此 SQL Server 应该能够推断出查询最多会返回几行，因此，键查找和排序操作将比索引扫描快得多。

我还尝试创建一个包含 auftrag_produktion 和 prod_soll_über 的非聚集索引，但它并没有改变游标的执行计划（尽管它确实使直接查询更快）。

这是完整的表定义，以防相关：

CREATE TABLE [auftrag_prod_soll](
    [auftrag_produktion] [int] NULL,
    [losgrößenunabh] [smallint] NOT NULL,
    [stückliste_vorh] [smallint] NOT NULL,
    [erledigt] [smallint] NOT NULL,
    [ext_wert_ueberst] [smallint] NOT NULL,
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [prod_soll_über] [int] NULL,
    [artikel] [int] NULL,
    [gesamtmenge_soll] [float] NULL,
    [produktionstext] [nvarchar](max) NULL,
    [reihenfolge] [int] NULL,
    [reihenfolge_druck] [int] NULL,
    [infkst_unter] [int] NULL,
    [ebene] [smallint] NULL,
    [bezeichnung] [varchar](50) NULL,
    [extern_text] [nvarchar](max) NULL,
    [intern_preis] [float] NULL,
    [intern_wert] [float] NULL,
    [extern_preis] [float] NULL,
    [extern_wert] [float] NULL,
    [extern_proz] [float] NULL,
    [dummyfeld] [varchar](50) NULL,
    [mengeneinheit] [varchar](50) NULL,
    [artikel_art] [smallint] NULL,
    [s_insert] [float] NULL,
    [s_update] [float] NULL,
    [s_user] [varchar](255) NULL,
    [preiseinheit] [float] NULL,
    [memo] [nvarchar](max) NULL,
    [lager_nummer] [int] NULL,
    [zweitmenge] [float] NULL,
    [zweit_einheit] [float] NULL,
    [zweit_mengeneinh] [varchar](50) NULL,
    [kst_preis1] [float] NULL,
    [kst_preis2] [float] NULL,
    [kst_preis3] [float] NULL,
    [kst_preis4] [float] NULL,
    [p_position] [int] NULL,
    [zeilen_status] [int] NULL,
    [fs_adresse_lief] [uniqueidentifier] NULL,
    [t_artikel_stückliste] [int] NULL,
    [div_text1] [varchar](255) NULL,
    [div_text2] [varchar](255) NULL,
    [menge_urspr] [float] NULL,
    [fs_artikel_index] [uniqueidentifier] NULL,
    [s_guid] [uniqueidentifier] ROWGUIDCOL  NOT NULL,
    [gemein_kosten] [float] NULL,
    [fs_leistung] [uniqueidentifier] NULL,
    [sonderlogik_ok_rech] [smallint] NOT NULL,
    [sonderlogik_ok_manuell] [int] NULL,
    [menge_inkl_frei] [float] NULL,
    [art_einheit] [int] NULL,
    [drittmenge] [float] NULL,
 CONSTRAINT [PK__auftrag_prod_sol__50E5F592] PRIMARY KEY CLUSTERED ([ID] ASC)
) 

CREATE NONCLUSTERED INDEX [artikel] ON [auftrag_prod_soll] ([artikel] ASC)
CREATE NONCLUSTERED INDEX [auftrag_produktion] ON [auftrag_prod_soll] ([auftrag_produktion] ASC)
CREATE NONCLUSTERED INDEX [dummyfeld] ON [auftrag_prod_soll] ([dummyfeld] ASC)
CREATE NONCLUSTERED INDEX [fs_adresse_lief] ON [auftrag_prod_soll] ([fs_adresse_lief] ASC)
CREATE NONCLUSTERED INDEX [fs_artikel_index] ON [auftrag_prod_soll] ([fs_artikel_index] ASC)
CREATE NONCLUSTERED INDEX [fs_leistung] ON [auftrag_prod_soll] ([fs_leistung] ASC)
CREATE NONCLUSTERED INDEX [lager_nummer] ON [auftrag_prod_soll] ([lager_nummer] ASC)
CREATE NONCLUSTERED INDEX [prod_soll_über] ON [auftrag_prod_soll] ([prod_soll_über] ASC)
CREATE NONCLUSTERED INDEX [reihenfolge] ON [auftrag_prod_soll] ([reihenfolge] ASC)
CREATE UNIQUE NONCLUSTERED INDEX [s_guid] ON [auftrag_prod_soll] ([s_guid] ASC)
CREATE NONCLUSTERED INDEX [s_insert] ON [auftrag_prod_soll] ([s_insert] ASC)
CREATE NONCLUSTERED INDEX [u_test] ON [auftrag_prod_soll] ([auftrag_produktion] ASC,
    [prod_soll_über] ASC)
CREATE NONCLUSTERED INDEX [zeilen_status] ON [auftrag_prod_soll] ([zeilen_status] ASC)
ALTER TABLE [auftrag_prod_soll] ADD  DEFAULT ((0)) FOR [losgrößenunabh]
ALTER TABLE [auftrag_prod_soll] ADD  DEFAULT ((0)) FOR [stückliste_vorh]
ALTER TABLE [auftrag_prod_soll] ADD  DEFAULT ((0)) FOR [erledigt]
ALTER TABLE [auftrag_prod_soll] ADD  DEFAULT ((0)) FOR [ext_wert_ueberst]
ALTER TABLE [auftrag_prod_soll] ADD  CONSTRAINT [DF__auftrag_p__s_gui__28A2FA0E]  DEFAULT (newid()) FOR [s_guid]
ALTER TABLE [auftrag_prod_soll] ADD  DEFAULT ((0)) FOR [sonderlogik_ok_rech]

即使使用游标，我如何帮助 SQL Server 找到好的查询计划？

我通过禁用“reihenfolge”索引暂时“修复”了这个问题，但我仍然想了解为什么会发生这种情况，以便将来避免此类问题。

@p3在调用 之后，@p4、 和的值@p5保持在它们的初始值 (4, 1, -1) sp_cursoropen，但是只要我通过删除 reihenfolge 索引“解决”问题，它们就会切换到 (1, 1, 0) .

重现场景：

CREATE TABLE test (
  ID int IDENTITY(1,1),
  mykey nvarchar(255) NOT NULL,
  exp_date datetime,
PRIMARY KEY (ID));
GO

CREATE INDEX not_expired_keys ON test (exp_date, mykey);

INSERT INTO test (mykey, exp_date) VALUES ('A', NULL);

我开始交易1：

-- add key B
BEGIN TRANSACTION;
INSERT INTO test (mykey, exp_date) VALUES ('B', NULL);
...

然后并行执行事务 2：

-- expire key A
BEGIN TRANSACTION;
UPDATE test SET exp_date = GETDATE() WHERE exp_date IS NULL AND mykey = 'A'; -- <-- Blocking
ROLLBACK;

事实证明，事务 1 的未提交 INSERT 会阻止事务 2 的 UPDATE，即使它们影响不相交的行集（mykey = 'B'vs. mykey = 'A'）。

观察：

• 阻塞也发生在最低事务隔离级别上READ UNCOMMITTED。
• 如果我将唯一索引放在mykey. 不幸的是，我不能这样做，因为一旦密钥过期，密钥名称就可以重复使用。

我的问题：

• （出于好奇：）为什么这些语句即使在READ UNCOMMITTED级别上也会相互阻止？

• 有没有一种简单可靠的方法可以让它们不互相阻挡？

有一个很好的 SQL Server 函数SUSER_SNAME，可以将server_user_sid转换为用户名。这对于将众所周知的 Windows SID 转换为（可能本地化的）用户名很有用。

例子：

SELECT SUSER_SNAME(0x01020000000000052000000021020000)

-- yields 'BUILTIN\USERS' (or, on a German system, 'VORDEFINIERT\Benutzer')

通过一些谷歌搜索和反复试验（=手动创建用户并sys.server_principals随后检查），我确定了以下等价物：

Built-in User/Group    Windows SID      SQL Server server_user_sid

BUILTIN\USERS          S-1-5-32-545     0x01020000000000052000000021020000
NT AUTHORITY\SYSTEM    S-1-5-18         0x010100000000000512000000

将 Windows SID 转换为 SQL Server server_user_sids 的算法是什么？

这个高度赞成的 SO 答案建议将图像放在单独的表中，即使与另一个表只有 1:1 的关系：

如果您决定将图片放入 SQL Server 表中，我强烈建议您使用单独的表来存储这些图片 - 不要将员工照片存储在员工表中 - 将它们保存在单独的表中。这样，假设您并不总是需要选择员工照片作为查询的一部分，那么 Employee 表可以保持精简、平均和非常高效。

为什么？我的印象是SQL Server 只在表中存储了一个指向某些专用 BLOB 数据结构的指针，那么为什么还要手动创建另一层间接呢？它真的能显着提高性能吗？如果是，为什么？

sp_getapplock存储过程具有以下返回值：

0：成功同步授予锁。
1：等待其他不兼容的锁释放后，锁被成功授予。
-1：锁请求超时。
-2：锁定请求被取消。
-3：锁定请求被选为死锁牺牲品。
-999：表示参数验证或其他调用错误。

我正在编写一个用于调用sp_getapplock我们的数据访问层的包装器，我想知道在哪些情况下可以返回 -2，以便我可以抛出一个描述性和有用的异常。很明显 -1 和 -3 的返回值意味着什么，我可以轻松创建导致返回这些值的测试条件。我将如何设法获得 -2 的返回值？

假设我希望所有记录的前缀都介于两个用户提供的长度相同的字母数字值之间。因此，如果用户输入A010and A025，我想返回A0101, A0200and A0259。

我试过的：

1. 显然，我不能使用WHERE myText BETWEEN @from and @to，因为那不会返回A0259。

2. 从技术上讲，WHERE LEFT(myText, @len) BETWEEN @from AND @to将正是我想要的，但这会扼杀 SARGability。

3. 我可以使用WHERE myText BETWEEN @from and @to + 'zzzzzzzzzzz'，但这是一个丑陋的 hack 并且可能容易出错。（z真的是最高字符吗？我是否使用了足够的“填充”字符？）

4. 我可以“展开”范围并搜索每个可能的前缀，例如WHERE (myText LIKE 'A01%' OR myText LIKE 'A020%' OR myText LIKE 'A021%' ...)，但这需要大量工作。

我错过了一些聪明的解决方案吗？我可能会使用选项 3 来解决问题（因为我知道允许字符的长度和范围），但我对一般情况很好奇。

我有一个log带有ID标识列的表。多年来一切正常；然后，昨天，我在日志中看到以下错误：

该语句已终止。
违反主键约束“PK__log__ID__3B40CD36”。无法在对象“dbo.log”中插入重复键。重复键值为 (295992)。

INSERT INTO log (datum, zeit, benutzer, modul, prozedur, code, zeile, bez1, bez2, tech_info) VALUES ('20151126 00:00:00.000', '19000101 18:26:45.121', 'Customer', '' , '', 'WShop-Trans', 0, '1 Datensätze für Tabelle adresse gesendet.', '', '')

我检查了 IDENTITY 种子，它看起来不错：

查询：DBCC CHECKIDENT（日志）

结果：检查身份信息：当前身份值“296021”，当前列值“296021”。
DBCC 执行完成。如果 DBCC 打印错误消息，请联系您的系统管理员。

查询：SELECT MAX(ID) FROM log

结果：296021

表上没有触发器，也没有人在弄乱种子值（我是管理数据库服务器的人，所以我很确定）。

到目前为止，这是一次性事件，我无法重现它。

我看起来只是一个 SQL Server 故障，但我很好奇：这是一个已知的错误，还是对此有任何其他合理的解释？SQL Server 版本是Microsoft SQL Server 2012 - 11.0.2100.60 (X64).

为了完整起见，这是完整的表格脚本：

CREATE TABLE [log](
    [datum] [datetime] NULL,
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [zeit] [datetime] NULL,
    [benutzer] [varchar](255) NULL,
    [modul] [varchar](255) NULL,
    [prozedur] [varchar](255) NULL,
    [code] [varchar](255) NULL,
    [zeile] [int] NULL,
    [bez1] [text] NULL,
    [bez2] [text] NULL,
    [tech_info] [text] NULL,
    [pc_name] [varchar](255) NULL,
    [app_name] [varchar](255) NULL,
    [s_insert_user] [nvarchar](255) NULL,
    [s_insert_dat] [datetime] NULL,
    [s_update_user] [nvarchar](255) NULL,
    [s_update_dat] [datetime] NULL,
    [fs_mandant] [uniqueidentifier] NULL,
 CONSTRAINT [PK__log__ID__3B40CD36] PRIMARY KEY CLUSTERED ([ID] ASC)
)

CREATE NONCLUSTERED INDEX [code] ON [log] ([code] ASC)
CREATE NONCLUSTERED INDEX [datum_zeit] ON [log] ([datum] ASC, [zeit] ASC)
CREATE NONCLUSTERED INDEX [fs_mandant] ON [log] ([fs_mandant] ASC)
CREATE NONCLUSTERED INDEX [modul] ON [log] ([modul] ASC)

安装 SQL Server 时，您可以指定 SQL Server 管理员，即最初具有 sysadmin 角色的用户列表。默认情况下，此列表包含当前用户。

_{（图片引自https://msdn.microsoft.com/en-us/library/dd578652.aspx。）}

这个默认值让我觉得很奇怪。不是BUILTIN\Administrators比当前用户更明智的选择吗？毕竟，Windows 身份验证的重点不是不必管理两个单独的用户/组目录吗？并且本地管理员无论如何都可以获得系统管理员权限，如果他们愿意的话，所以它也不是一个真正的安全功能。

另一方面，SQL Server 是由比我聪明得多的人编写的，所以这个默认值实际上可能有一个很好的理由。它是什么？

到目前为止，我的印象是 SQL Server 中有两种类型的统计对象：

• 自动创建的统计信息，由 SQL Server 在索引列或单个列上创建以提高性能，以及

• user-created statistics，这是用CREATE STATISTICS语句手动创建的。

因此，我很惊讶地看到以下查询：

SELECT s.name, s.stats_id, s.auto_created, s.user_created
  FROM sys.stats AS s
       INNER JOIN sys.stats_columns AS sc ON s.object_id = sc.object_id AND s.stats_id = sc.stats_id
       INNER JOIN sys.columns AS c ON sc.object_id = c.object_id AND sc.column_id = c.column_id
       INNER JOIN sys.tables AS t ON c.object_id = t.object_id
 WHERE t.name = 'mytable'

产生以下结果：

name                    stats_id   auto_created   user_created
--------------------------------------------------------------
PK__mytable__7A73B1B8       1          0              0
SomeIndex                   2          0              0
SomeIndexedColumn1          3          0              0
SomeIndexedColumn2          4          0              0
SomeIndexedColumn3          5          0              0
SomeColumn                  6          0              1

那些既不是 auto_created 也不是 user_created 的统计信息是什么？我查看了 sys.stats 的文档，但没有在那里找到答案。

显然，SQL Server 在创建表时存储当前的 ANSI_NULL 设置（请参阅此处和此处的相关问题）。

但是，当我执行

SELECT * FROM myVeryOldTable WHERE someFieldWithNullValues = NULL

我得到零结果，即使旧表是使用 ANSI_NULL OFF 创建的。因此，显然，SQL Server 使用当前的连接设置，即 ANSI_NULL ON。

如果是这样，存储在表中的设置有什么区别（除了在各种情况下会造成麻烦）？如果连接设置总是覆盖表设置，为什么要存储它呢？

在一些 SQL Server 开发人员中，人们普遍认为NOT IN速度非常慢，应该重写查询，以便返回相同的结果但不使用“evil”关键字。（例子）。

这有什么道理吗？

例如，SQL Server 中是否存在某些已知错误（哪个版本？）导致查询使用NOT IN的执行计划比使用的等效查询更差

• 结合检查LEFT JOIN或NULL
• (SELECT COUNT(*) ...) = 0在WHERE条款中？

当连接因任何原因关闭时，我可以告诉 SQL Server “做某事”（例如释放应用程序级锁）吗？

背景：我想在应用程序级别而不是数据库级别锁定记录。但是，当应用程序崩溃时，我无法释放锁。基本上，我在我的应用程序中实现了以下算法：

function editRecord(recordId):
    begin transaction
    if (select lockedBy from myTable where id = recordId) is not empty:
        commit
        show "Sorry, record already in use by ..."
    else
        update myTable set lockedBy = current_user() where id = recordId
        commit
        show UI window to let user edit and update record
        update myTablet set lockedBy = empty where id = recordId

我试图找出在连接崩溃时是否有一种简单的方法来摆脱应用程序级锁定。

假设我有一个 SELECT 语句如下：

SELECT ..., field1
  FROM ...
 GROUP BY field1

现在假设我想返回第二个字段，field2. 碰巧的是，field2 在功能上依赖于 field1（例如，field1 和 field2 可能来自同一个表，而 field1 是该表的主键）。我现在有两种等效的方法来将 field2 添加到查询中：

选项1：

SELECT ..., field1, field2
  FROM ...
 GROUP BY field1, field2

选项 2：

SELECT ..., field1, MIN(field2)  /* or some other, arbitrary aggregate function */
  FROM ...
 GROUP BY field1

同样，由于 field2 在功能上依赖于 field1，因此两个查询应该返回相同的结果集。

有什么充分的理由更喜欢一种选择吗？

ANSI SQL 标准为空结果集上的聚合函数定义（第 6.5 章，集合函数规范）以下行为：

COUNT(...) = 0
AVG(...) = NULL
MIN(...) = NULL
MAX(...) = NULL
SUM(...) = NULL

为 AVG、MIN 和 MAX 返回 NULL 非常有意义，因为空集的平均值、最小值和最大值是未定义的。

然而，最后一个让我感到困扰：从数学上讲，空集的 SUM 是明确定义的：0. 使用 0（加法的中性元素）作为基本情况使一切保持一致：

SUM({})        = 0    = 0
SUM({5})       = 5    = 0 + 5
SUM({5, 3})    = 8    = 0 + 5 + 3
SUM({5, NULL}) = NULL = 0 + 5 + NULL

定义SUM({})为null基本上使“无行”成为不适合其他情况的特殊情况：

SUM({})     = NULL  = NULL
SUM({5})    = 5    != NULL + 5 (= NULL)
SUM({5, 3}) = 8    != NULL + 5 + 3 (= NULL)

我错过的选择是否有一些明显的优势（SUM 为 NULL）？

我知道我可以使用以下方法查询有效权限sys.fn_my_permissions：

USE myDatabase;
SELECT * FROM fn_my_permissions('dbo.myTable', 'OBJECT') 

 entity_name | subentity_name | permission_name 
------------------------------------------------
 dbo.myTable |                | SELECT          
 dbo.myTable |                | UPDATE          
 ...

myTable这告诉我当前用户在数据库中是否有 SELECT、INSERT、UPDATE 等权限myDatabase。

是否可以轻松找出用户拥有这些权限的原因？例如，我希望有一个fn_my_permissions_ex输出附加reason列的函数：

USE myDatabase;
SELECT * FROM fn_my_permissions_ex('dbo.myTable', 'OBJECT') 

 entity_name | subentity_name | permission_name | reason
------------------------------------------------------------------------------------------------------------------------------------
 dbo.myTable |                | SELECT          | granted to database role public
 dbo.myTable |                | UPDATE          | member of group MYDOMAIN\Superusers, which belongs to database role db_datawriter
 ...

不幸的是，我在 SQL Server 文档中找不到这样的函数。是否有提供此功能的工具或脚本？