在 SQL Server 中使用 ODBC 日期字符串文字是否有任何性能缺点？它比常规字符串日期文字更好吗？

Question

我有一个 TSQL 视图，可以在 SQL Server 2016 环境中处理多个 GB 的数据。在此视图中，我多次比较 DateTime 值是否在静态日期之前/之后，传统上表示为字符串文字，如'2018-07-11'.

一个比较的例子是：

SELECT MyId, MyValue FROM MyTable WHERE MyDate = '2018-07-11'

在寻找使用 DateTime 文字而不是字符串的方法时，我遇到了使用 ODBC DateTime 字符串的示例，如下所示：

SELECT MyId, MyValue FROM MyTable WHERE MyDate = {d '2018-07-11'}

当我比较查询计划时，即使我编写了更高级的查询，我也会得到相同的结果。

我开始使用这种格式是为了防止在查询中将字符串自动转换为 DateTime，但我找不到任何好的文档来解释使用 ODBC 函数的任何副作用。我不确定这是否与字符串文字的行为相同，或者是否被解释为日期。

如果这是一个 UDF 或存储过程，我可以声明一个 DateTime 变量以在查询中使用，但在 VIEW 中这是不可能的，也不可行，因为在查询中有很多 DateTime 文字。查询的实际版本。

总之，是否有人有任何具体理由支持 或 反对使用这种{d '2018-07-11'}格式（除了它在非 SQL Server 环境中可能无效之外）？

我想确保我不会在代码审查中搬起石头砸自己的脚。

PS：对于模糊的例子和半开放式的问题，我深表歉意，我不允许透露任何实际的源代码。

谢谢！

编辑：我忘了提及我也可以使用DATEFROMPARTS(2018, 07, 11)，但我不确定查询优化器是否会奇怪地看待它。

Answer 1

ODBC 文字有一个微小的优点，即它永远不能被解释为 YYYY-DD-MM，而通过一种国际化设置就可以实现这一点。

您可以通过使用'YYYYMMDD'格式来避免歧义。此格式不受设置影响。

我不喜欢使用 ODBC，只是因为它似乎在查询中涉及更多混乱。我承认也更喜欢连字符形式（与 ISO 标准和其他数据库一致）。但你有三种选择。对于通用目的来说，可能最安全的、仅限 SQL-Server 的代码是不带连字符的形式。