只需将一些代码从OracleDB移植到MariaDB，并将某些OracleDB表达式（如SYSDATE - ? / 1440）转换为MariaDB表示法（这似乎很合适：）NOW() - interval 60 * ? second。
偶然发现我怀疑是已知错误或已记录行为（请帮助），同时调试了以下行为异常的表达式（基本上比较了两个历史“锁”的持续时间）
WHERE (a.expirationDt - a.acquisitionDt) > (b.expirationDt - b.acquisitionDt)
在OracleDB中-此表达式始终有效/可靠。在MariaDB中-似乎取决于所减去的时间戳是否属于同一分钟（然后相减得出正确的秒数），或者来自两个不同的分钟（那么相减结果似乎被填充/四舍五入到最接近的分钟） ），从而产生违反直觉的结果。
这是一个小演示（主要使用now()和“ 20秒前”）：
root@localhost> maria "select now(), now() - interval 60 * 1/3 second, now() - interval 60000000 * 1/3 microsecond, now() - (now() - interval 60 * 1/3 second), now() - (now() - interval 60000000 * 1/3 microsecond), TIMESTAMPDIFF( second, now() - interval 60 * 1/3 second, now()) from dual"
2020-02-03 13:51:59.0
2020-02-03 13:51:39.0
2020-02-03 13:51:39.0
20.0000
20.000000
20
root@localhost> maria "select now(), now() - interval 60 * 1/3 second, now() - interval 60000000 * 1/3 microsecond, now() - (now() - interval 60 * 1/3 second), now() - (now() - interval 60000000 * 1/3 microsecond), TIMESTAMPDIFF( second, now() - interval 60 * 1/3 second, now()) from dual"
2020-02-03 13:52:02.0
2020-02-03 13:51:42.0
2020-02-03 13:51:42.0
60.0000
60.000000
20
我知道它TIMESTAMPDIFF看起来不错，并且可以相应地重写SQL（只需要确保如何以亚秒级精度正确工作即可，因为“ 20.4秒> 20.2秒”将false在四舍五入到1秒精度后返回）。
我的主要问题-我的MariaDB设置是否有问题？还是特定MariaDB版本中的已知错误？还是设计使然？
这是设计使然。MariaDB / MySQL中的DATETIME算术不符合您的期望。
表示为YYYY-MM-DD HH：MM：SS的DATETIME值被强制转换为表示为YYYYMMDDHHMMSS的十进制数（并用零值填充以表示丢失的秒数）。
来自MySQL的示例：
mysql> SELECT CAST('2020-02-02 00:01' AS DATETIME) - CAST('2020-02-02 00:00:01' AS DATETIME),
-> 20200202000100 - 20200202000001 \G
*************************** 1. row ***************************
CAST('2020-02-02 00:01' AS DATETIME) - CAST('2020-02-02 00:00:01' AS DATETIME): 99
20200202000100 - 20200202000001: 99
1 row in set (0.00 sec)
正如您所发现的，对于这种算术，必须使用特定于日期/时间操作的函数。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句