日期文字是否比使用 to_date 更快？答案

【问题标题】：Are date literals faster than using to_date?日期文字是否比使用 to_date 更快？
【发布时间】：2014-08-06 16:07:17
【问题描述】：

其中哪个更快？还有其他区别吗？

一个。

SELECT
    *
FROM
    my_table
WHERE
    my_date >= DATE '2013-01-17';

SELECT
    *
FROM
    my_table
WHERE
    my_date >= TO_DATE('17/01/2013','dd/mm/yyyy');

【问题讨论】：

输入文字比使用格式掩码的 to_date 更快（当然，它应该总是有）；这算不算？使用select ... from dual 在 PL/SQL 循环中测试它们似乎无法区分。
很难测试，因为涡旋中有一些波动，但在 100,000 次迭代中，它们通常在大约 50 毫秒内。日期文字更常见，但它们只是相同。换句话说，可能会有差异，但最多只有 0.5 微秒（即不用担心 Alex 和 Justin 所说的）。

标签： oracle

【解决方案1】：

极不可能有有意义的不同。如果您的瓶颈是您可以多快地将字符串文字转换为日期，我倾向于宣布胜利并为历史上第一个完美调整的应用程序干杯。或者认真质疑我做错了什么，导致需要将这么多文字转换为日期。

理论上，使用日期文字应该会快一点，因为格式是固定的，因此您不必先解析格式掩码然后再解析字符串的复杂性。但这假设 Oracle 在内部打扰编写优化的日期文字路径，而不是在内部通过 to_date 代码路径（这可能取决于特定的 Oracle 版本）。而且，就像我说的那样，如果您处于这种差异很重要的位置，那么您要么做错了什么，要么已经彻底调整了应用程序，几乎可以肯定是时候停止了。

【讨论】：

【解决方案2】：

是的，日期文字更快。 TO_DATE 是一个错误，应该避免。（这不是总是一个错误，但总是对它持怀疑态度是有帮助的。）

根据 Stackoverflow 问题，日期处理是 Oracle 最棘手的部分之一。相信字符串和日期是同一件事会导致很多问题。了解文字的重要性并始终使用正确的数据类型将间接提高性能。例如，当开发人员停止不断地将字符串转换为日期时，实体-属性-值反模式看起来更加可疑。

确实，处理日期文字和TO_DATE 的时间可能相同或不相关。无论如何，日期文字在内部转换为 TO_DATE 也是如此。但性能远不止这些。从编译器和优化器的角度来看，日期文字更容易理解代码，从而提高性能。

以下是日期文字可以显着提高性能的两个示例。

减少硬解析

国家语言支持 (NLS) 使 Oracle 在使用 TO_DATE 时难以准确区分变量和文字。

我们可以假设我们在美国使用公历编写英语语言。而且我们可能经常（不公平地）利用美国编码霸权并假设其他开发人员了解我们的系统。但优化器必须假设最坏的情况并非常仔细地检查日期字符串。

接受这个陈述：

select * from dual where trunc(sysdate) = to_date('06-AUG-2014', 'DD-MON-YYYY');

Oracle 对其进行解析，然后存储一个 SQL_ID，它是整个字符串的哈希值。但是对于日期，如果许多 NLS 参数之一发生更改，则完全相同的语句具有不同的含义。更改 NLS 参数可能会导致使用模棱两可的TO_DATE 增加硬解析。日期文字总是以相同的方式解析。

更好的执行计划

与解析问题类似，当 Oracle 不能完全理解谓词的含义时，可能会导致执行计划不佳。例如，在this answer 中，我展示了TO_DATE 格式的细微变化可以产生静态和动态分区修剪之间的变化。这种变化会导致更糟糕的统计数据，从而导致糟糕的执行计划。

总结

始终使用日期文字而不是 TO_DATE。性能通常是相同的。但是在某些情况下，日期文字明显更快，间接导致更好的编码实践，更加标准化（ISO 8601），可以在编译时而不是运行时检查，对国际观众来说不那么模棱两可，并且更容易输入。

使用日期文字是您可以做出的为数不多的编码风格决策之一，它在所有可能的方面都更好。

【讨论】：