检查记录是否存在 - 性能答案

【问题标题】：Check if record exists - performance检查记录是否存在 - 性能
【发布时间】：2014-07-07 08:28:25
【问题描述】：

我有一个包含大量数据的表。此表的用途是用户事务。

我将从第三方经常调用的网络服务插入此表。

第三方将提供参考代码（很可能是字符串）。

这里的要求是我需要检查这个参考代码是否已经被插入。如果存在，只需返回详细信息，不要做任何其他事情。如果它没有按预期创建事务。这背后的原因是在收到请求后可能会失去与服务的通信。

我对此有一些性能问题，因为搜索将在字符串值以及大表上完成。大多数情况下，事务不会存在于数据库中，因为这只是一种预防措施。

我在这里要求的不是代码，而是性能的最佳方法。

【问题讨论】：

【解决方案1】：

正如您的主题所表明的，如果您正在尝试评估 EXISTS（从 Sometable 中选择 1），那么不会有太多的性能惩罚。这是因为您不会只写一堆 1（表示内部查询）来将结果评估为布尔值。

另一方面是在参考代码字段上提供的非聚集索引。如果参考代码的长度可以说它是一个固定长度的字符串 (CHAR(50) 那么 B 树也将是最佳的。

我不确定数据一致性要求，因此除非您具有高度跨国读写，否则正常的 readcommitted 不会造成任何伤害。

【讨论】：

我知道存在是有效的，因为它会在找到的第一个结果上停止。但正如我所说，大多数情况下，事务不会存在，所以 select exists 无论如何都会遍历整个表。我们正在计算每秒大约 15-30 次写入。
我希望您所说的表大小约为 1 -200 万行，高于您将看到性能上的显着差异主要归因于表的设计方式。有多少数据被压缩到扩展和页面中，由于修改导致的碎片，文件 io 等。这些是表增长到高值后很快要解决的问题。
其实每个月都会建表来减少表的大小。最终将达到每月 1-2 百万行。
这是一个很好的策略，我认为您将在主键上使用身份种子以减少索引碎片。还要查看数据的水平分区并将表移动到不同的文件组，如果它与其他表相比有巨大的增长，这将有助于稍后实施优化的备份策略并在 SAN 上或使用 RAID 时改进文件 io
会有身份种子是的。我考虑过进行水平分区以及表在这方面也会非常大。