SQL Server 2008：where 子句小数部分中的小数列影响查询速度答案

【问题标题】：SQL Server 2008 : Decimal column in where clause decimal part effects query speedSQL Server 2008：where 子句小数部分中的小数列影响查询速度
【发布时间】：2014-02-19 19:33:45
【问题描述】：

我有一个十进制 (15,10) 列，其中包含创建日期的 OLE 自动化格式。当您执行类似的查询时

SELECT * FROM SOMETABLE WHERE RECORDTIMEOA BETWEEN 41667 AND 41667.9999999999 --Decimal Part is 10 characters

查询在 8 或 9 秒内返回所有结果。但不是使用 41667 整数值，而是使用 41667.0000000000，然后查询返回 1 秒内的所有结果。当您将 9 或 8 个字符放在第二个小数部分时也会发生这种情况，例如

SELECT * FROM SOMETABLE WHERE RECORDTIMEOA  BETWEEN 41667 AND 41667.99999999 --Decimal part is 8 characters

我在该列上有一个非聚集索引，也许它会影响这个问题，所以我想知道下面的查询之间有什么区别，为什么第一个在 8 秒内返回而其他在 1 秒内返回？

SELECT * FROM SOMETABLE WHERE RECORDTIMEOA  BETWEEN 41667 AND 41667.9999999999
SELECT * FROM SOMETABLE WHERE RECORDTIMEOA  BETWEEN 41667 AND 41667.9999999
SELECT * FROM SOMETABLE WHERE RECORDTIMEOA  BETWEEN 41667.0000000000 AND 41667.9999999999

如果你能帮忙，请告诉我..

更新：我正在为查询添加两个执行计划

UPDATE : 这是应用 CAST 方法后的执行计划

【问题讨论】：

能否请您发布两种情况下的查询执行计划？
好的，我已经添加了两个执行计划，第一个是慢的，底部是快的。
这表现如何？ SELECT * FROM sometable WHERE recordtimeoa >= Cast(41667 As decimal(15,10)) AND recordtimeoa < Cast(41668 As decimal(15,10))
P.S. RID 查找是罪魁祸首。阅读 Aaron Bertrand 的这篇文章：mssqltips.com/sqlservertip/2195/…“...[RID] 查找发生在索引不满足查询（非覆盖查询）时，因此需要从聚集索引或堆中检索其他数据。. 。”
如果你使用 cast 方法，那么你可能需要很长时间才能处理大行，我们在这里谈论多少行？您可以发布应用了演员阵容的执行计划吗？

标签： sql sql-server sql-server-2008 tsql database-performance

【解决方案1】：

作为使用包含下限和上限的 Between 函数的替代方法，您可以将 where 子句转换为使用 >= and < 这将是一个很好的测试来检查您的性能并查看执行计划以了解 SQL 服务器的运行情况使用索引。

SELECT * FROM SOMETABLE WHERE RECORDTIMEOA >= 41667 AND RECORDTIMEOA < 41668

这是来自Turgay Sahtiyan blog 的精彩帖子，其中讨论了where 子句中的数据类型不匹配以及它导致的性能问题。以下文章列出了所有隐式和显式转换：http://technet.microsoft.com/en-us/library/ms191530.aspx。

【讨论】：

感谢您的建议，但我已经尝试过没有任何改变，而且如果您在查询中输入两个整数，它可以正常工作（不到 1 秒）。
没有查看执行计划的 XML 数据以获取详细信息，您的问题很可能来自强制 SQL Server 查找包含在索引中的更精确的值。因此，当您只有 7 个小数位时，它只会跳到正确的位置，而不是使用 10 个小数位，它必须查看每个值。您在列中实际拥有的最大精度点是多少？

【解决方案2】：

可能是这里正在进行的数据转换导致索引无法使用。最好的办法是查看 SSMS 为这两个查询生成的查询计划，并查看是否正在对较慢的查询进行扫描而不是搜索。

如果两个查询都在进行搜索，则可能是缓存的情况。行（和查询计划）已经在内存中，缓存，以便更快的查询。

【讨论】：

这两个查询都在进行索引搜索，但快速的查询成本为 %2，较慢的查询成本为 %91。我认为在这种情况下不存在缓存问题。