隐式转换不影响性能

Question

我已经阅读了关于索引的隐式转换影响性能的内容，因此在以下查询中

select count(*)
from fpc
where SKey in (201701, 201702)

因为 SKey 是 int 类型，如果我将上面的查询更改为

select count(*)
from fpc
where SKey in ('201701', '201702')

性能会下降。

我在一个表（有数百万行）上测试了这个。问题是为什么我没有看到执行计划和时间上的任何差异。

我在 SKey 上有非聚集列存储索引。

每个 SKey 大约有 2000 万行，我有大约 100 个不同的 SKey

Answer 1

隐式转换的问题在于它会妨碍索引的有效使用。如果必须将函数应用于列以获取正确的比较值，则不能在搜索中使用对该列的索引查找。

但是，SQL Server 在必须比较不同类型的值时必须决定要转换哪个值。它根据其数据类型优先级规则执行此操作。

如果您查看该页面，您会看到integer值具有更高的优先级varchar。因此，该varchar值是被转换的值。

在您提供的示例中，索引列是一integer列，硬编码值是varchar(or char, or nvarchar- 的优先级都低于integer)。

因此，硬编码值被转换为整数。由于您的列未进行转换，因此仍可以使用索引。

注意：这不是唯一的因素。例如，在同一“系列”（例如，int和bigint）中的不同数据类型之间的转换仍将允许索引查找，无论索引列是哪种数据类型。

这就是为什么应该尽可能匹配数据类型，或者在需要时对非索引数据使用显式转换；通过控制转换过程，通常可以避免该问题。

就个人而言 - 这种优先顺序长期以来一直令人烦恼。如果您有一个字符值需要与数值进行比较，除非您明确执行转换，否则 SQL Server 将尝试将字符值（并不总是具有有效的数字表示形式）转换为数字，而不是转换数值（应始终具有有效的字符表示）。叹。

Bob Klimes指出了几篇相关的文章：

• 导致索引扫描的隐式转换，作者 Jonathan Kehayias，它进行了一项测试，以查看隐式转换时哪些数据类型会导致索引扫描；和
• 数据类型不匹配并不总是导致“不良”隐式转换和索引扫描，由 Kendra Little 撰写，涵盖了同一“系列”中不同类型之间的隐式转换仍然允许索引查找而不是索引扫描的事实。