Triynko's questions

有人说最好制作查询以避免重复的键异常，但我不相信这比仅设置IGNORE_DUP_KEY = ON索引更有效。

我的目标是在尝试更新这些行之前确保一个或多个用户存在一行或一组行。我这样做，以便当我尝试使用如下所示的更新语句更新行并且没有行受到影响时，这是因为[Count]谓词的部分不满足，而不是根本不存在的行（即[ID]不满足谓词的部分）：

UPDATE [Inventory]
SET [Count] = [Count] + 1
WHERE [ID] = 3 
AND ([Count] + 1) <= @MaxInventory

我可以运行EXISTS(SELECT 1 From [Inventory] WHERE [ID] = 3以检查该单行，并且仅在该行不存在时才插入该行。这只是避免了不必要的插入。如有必要，插入仍然必须与并发事务竞争，因此仍然可能发生重复键异常。

我很好奇IGNORE_DUP_KEY在这种情况下仅打开而不是允许抛出和捕获错误是否更高效。具体来说，我很好奇它是否与运行存在检查一样快甚至可能更快，只是尝试插入记录并让它忽略重复的键。

当我一次检查和初始化多个记录时，这变得更加重要。例如，如果我需要确保在单个更新语句中存在数千个用户的记录，那么如果我只是预先运行该插入语句，让它忽略重复的键，那么逻辑会简单得多。避免重复会更复杂，因为我必须首先查询不存在记录的表，然后尝试仅添加这些记录（同样，忽略重复键）。即使所有记录都存在，仅插入可能会更快。

我可以在中途遇到它并检查是否缺少任何记录，例如左连接或COUNT比较，但是如果忽略重复键的插入更快，为什么还要麻烦呢？

IGNORE_DUP_KEY使用并尝试插入而不是提前检查行是否存在是一个好主意吗？如果不是，为什么？

存在一个“批量查询”表，它有两列（BatchID、RecordID），它们都是 TSQL 类型的“唯一标识符”。唯一的聚簇键在（BatchID，RecordID）上，并且没有二级索引。

我们使用 SqlBulkCopy 将数千或数百万个 id 快速插入到单个批处理 id 下的表中，以便各种查询可以对其进行连接，以使用与该批处理关联的记录 id 集执行过滤。这种方法比尝试在查询字符串中发送所有 id 列表的多个查询要快得多。一旦查询完成，这批记录 id 就会被删除。当没有查询运行时，该表平均为空，但可能有数百个活动批次，因为我们每秒处理数千个可能使用该表的 API 请求。

我的问题是，如果有的话，DBA 需要什么样的维护步骤来维护这些表。例如，它是否会从定期索引重建中受益，或者 SQL Server 是否会自行处理已删除行的清理（释放页面块等）。此外，是否有任何特殊的表或聚集索引配置会有所帮助，特别是考虑到标识符是随机 Guid（唯一标识符）。

一般我们使用最新版本的SQL Server，企业版。有些服务器在 Azure 中，有些在 AWS 中。

我也有兴趣听到替代方案。例如，我假设这种方法最适合永久表，但我也可以创建一个会话本地临时表作为事务的一部分，该表在完成时被删除，而不是从永久表中插入和删除行。我只是不知道相比之下会如何。

select POWER(2.,64.)返回18446744073709552000而不是18446744073709551616. 它似乎只有 16 位精度（四舍五入）。

即使使精度明确select power(cast(2 as numeric(38,0)),cast(64 as numeric(38,0)))，它仍然返回舍入结果。

这似乎是一个非常基本的操作，因为它可以像这样以 16 位精度任意剥落。它可以正确计算的最高值只是POWER(2.,56.)，失败了POWER(2.,57.)。这里发生了什么？

真正可怕的是它select 2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.*2.;实际上返回了正确的值。简洁明了。