【问题标题】：SQL partial date comparisonSQL部分日期比较
【发布时间】：2017-11-08 11:12:42
【问题描述】：

比较日期/日期时间值的部分时，哪种方法最有效？比较日期时间月份的示例：

where insdate =DATEADD(month, DATEDIFF(month, 0, @insdate), 0)

或

where year(insdate)=year(@insdate) and month(insdate)=month(@insdate)

我正在使用 sql server

【问题讨论】：

标记您正在使用的 dbms。（DATETIME 和 DATEDIFF 都是产品特定的函数。）
发帖后如何编辑标签？
这很容易。点击“编辑”，添加另一个标签，点击“保存”。
使用对您来说“最干净”的任何内容。如果此查询被识别为实际性能热点，请测量不同的方法并查看其中任何方法是否满足您的要求。您无法通过尝试学习数千条“总是做 X 而不是 Y”形式的规则来学习编写“高性能”SQL（或任何其他语言，通常）。

标签： sql sql-server performance tsql datetime

【解决方案1】：

我不同意 Damien_The_Unbeliever 的断言，即您应该使用任何一种更清晰的方式，因为有客观原因表明一种方法会比另一种更好。其中最相关的是所谓的SARGability。

本质上，这指的是 SQL Server 是否可以按照其设计的有效方式使用您的值，例如利用索引。

您的两个示例中的差异很好地概括了here。

简而言之，如果在相等条件的两边都有函数或计算值，SQL Server肯定必须检查返回的每个值，而如果你应用 SARGability 原则从一开始，即使您没有立即看到任何显着的好处，您至少可以在以后需要时更好地实现这些好处。

【讨论】：

我很难理解您的链接的内容以及您在“而”之后的意思。据我了解，您对我说的是“尽可能多地尝试使用 sargable 的东西，尽管在这种特定情况下它可能无济于事”。我了解该答案如何涵盖性能问题的索引使用方面。 datediff、dateadd 和 year/month() 的每行计算如何？在我看来，前者的算法比后者的算法计算得要多得多，后者就像“作物”。不过，我只是在猜测，所以我问。
@GeorgeMenoutis 啊，我明白你在说什么。基本上，与正确设置查询以使用 SQL 引擎的内置优化相比，您可以选择的各种函数之间的计算时间差异将对您的查询运行时间产生微不足道的影响。如果您处于整体查询执行时间的千分之一秒很重要的情况下，那么无论如何您都应该测试编写查询的所有可能方式，因此这个讨论没有实际意义。
@GeorgeMenoutis 收藏（并阅读）Tibor 的网站，他在该网站上讨论了 tsql 的这个和其他重要方面。 karaszi.com/sqlserver/info_datetime.asp#Searching
@SMor 所问的问题不是如何使用这些功能，而是它们之间的性能如何。您的链接未提供这方面的任何信息。
@iamdave 如果将函数应用于列，则会阻止引擎使用有用的索引 - 换言之，可搜索性。并且鉴于 OP 发布的 2 个示例在逻辑上是 NOT 等效的，因此比较它们的“性能”基本上是没有意义的。 Tibor 通过有用的示例和对性能影响的说明解释了如何使用日期时间值进行搜索。

【解决方案2】：

在我看来，实施 Year 或 YearMonth 检查的最佳方法是以 YYYYMMDD 格式转换日期，然后使用它。

这是一个例子：

按年月日过滤

SELECT * FROM myTable 
WHERE CONVERT(VARCHAR,MyField,112) = 20170607

按年月过滤

SELECT * FROM myTable 
WHERE CONVERT(VARCHAR,MyField,112) / 100 = 201706

按年份过滤

SELECT * FROM myTable 
WHERE CONVERT(VARCHAR,MyField,112) / 10000 = 2017

肯定这个性能比使用 Year() ,Month() , DateAdd(), DateDiff() 函数更好。

【讨论】：

为什么“肯定”？我来自一个低级计算机设计领域，当我看到 year() 等函数时，我理解“切断其余部分”，这可能只是一个带有掩码的 AND 操作，它是一条 cpu 指令。相反，类型之间的转换会调用具有多条指令的算法。也许我在第 5 级（即 sql）上使用 1 级语言逻辑时注意力不集中，但这就是我认为的方式。请告诉我我应该怎么想。
@GeorgeMenoutis 如果您使用低级别，这是完全正确的，但 SQL Server 是一个关系引擎并实现不同的低级别逻辑......