MariaDB DATE 到文本，哪种方式？答案

【问题标题】：MariaDB DATE to text, which way?MariaDB DATE 到文本，哪种方式？
【发布时间】：2021-02-12 22:44:09
【问题描述】：

当使用 MariaDB (MySQL) 时，我们希望将 DATETIME 转换为可读的 DATE，并且至少知道以下方法，所有这些方法都会产生相同的日期输出，但是......这些之间是否存在任何实际的性能差异转换，因为对话将出现在大型数据集的几列中

DATE(NOW())
CAST(NOW() AS DATE)
DATE_FORMAT(NOW(), '%Y-%m-%d')
CONVERT(NOW(), DATE)

数据库位于网络服务器上，供其他用户使用，因此“反复试验”不会产生可靠的结果。我无法解释其他用户在数据库上运行的任何内容和/或可能同时发生的任何其他网络/服务器活动。制作本地副本会提供更多（但不是完全）稳定的结果，但在我们的公司设备上，我们无法获取数据库副本。

这个问题专门针对这四个选项与其他任何选项之间的区别，我可能没有考虑到“它们之间是否有任何实际区别”

【问题讨论】：

在大型数据集上测试所有这些选项，您就会得到答案！
数据库在网络服务器上，被其他用户使用，因此“反复试验”不会产生可靠的结果。我无法解释其他用户在数据库上运行的任何内容和/或可能同时发生的任何其他网络/服务器活动。
创建表的本地副本并在稳定的环境中执行测试。
抱歉，也许我的问题不够清晰；我不是在寻找“反复试验”的解决方案。
没有什么能阻止您在测试中设置本地实例

【解决方案1】：

性能没有显着差异。

但这应该比所有提到的都快：

CURDATE()

（如果您需要当前日期以外的内容，请参阅 O. Jones 的回答。）

另一点：任何“常量”表达式都将为查询计算一次，而不是每行一次。这意味着NOW() 或CURDATE() 的所有值在整个查询过程中都是相同的。

并且进一步指出DATE(column)对于大表的低效率。

【讨论】：

【解决方案2】：

如果它们出现在您的SELECT 子句中，则使用此类函数不会对查询性能产生任何显着影响。差异太小而无法衡量：每行最多只有几十纳秒。使用使您的查询最容易被下一个人阅读并且不要回头的那个。

DATE_FORMAT() 会生成一个文本字符串。除非您想控制报告中日期的确切格式，否则您应该避免使用这种格式。

如果它们出现在您的WHERE 子句中，它们可能会使 MySQL 无法在日期列上使用索引。例如，这会影响您的表现。

WHERE DATE(timestampcolumn) = DATE(NOW())    /* slow! */

这很慢，因为它必须评估表中每一行的DATE() 函数。您示例中的其他约定也是如此。

如果您想进行这种过滤，请改为这样做。

 WHERE timestampcolumn >= DATE(NOW())
   AND timestampcolumn <  DATE(NOW()) + INTERVAL 1 DAY

如果您在timestampcolumn 上有索引，则此WHERE 子句将对该索引进行范围扫描，从而节省您服务器上的大量工作。

【讨论】：

感谢您的建设性回答；我怀疑数据库引擎解释了函数，并且每个函数的实际执行都是相同的。
@Sean 这肯定是不是的情况！正如答案中指出的那样， date_format() 产生一个字符串，而不是日期，因此与所有其他列出的转换相比，它必须具有不同的执行。结果可能看起来一样，但不一样！