gpt4 book ai didi

mysql - SELECT 在 MySQL 上的奇怪行为

转载 作者:行者123 更新时间:2023-11-29 06:37:30 24 4
gpt4 key购买 nike

我多次观察到这种类型的表达式会跳过行,并且一直想知道这是一个错误还是它是否有意义 - 至少在技术上是这样。查询的目的是生成顺序表内容。主要是 DATE 或 DATETIME。

t 是任何至少有 30 行的表格。

此版本按预期生成结果:

set @date = "2012-01-01";

select
@date := date_add(@date, interval 1 day) as d
from t
#having d < "2012-01-31"
limit 30
;

输出:

'2012-01-02'
'2012-01-03'
'2012-01-04'
...
'2012-01-31'

现在包括 HAVING 条件(所以我不必使用数字来限制我想要生成的行数,而是可以简单地指定一个上限):

set @date = "2012-01-01";

select
@date := date_add(@date, interval 1 day) as d
from t
having d < "2012-01-31"
limit 30
;

输出:

'2012-01-03'
'2012-01-05'
'2012-01-07'
...
'2012-01-29'
'2012-01-31'

但请注意 - 这是一个 WHY 问题 - 而不是 HOW 问题。

最佳答案

问题是当您调用列 d 时在你的HAVING子句,它计算表达式 @date := date_add(@date, interval 1 day)再次。这意味着 interval 1 day添加两次到初始 @date变量,因此为什么你的条目有差距。您可以通过添加额外条件来验证这一事实,例如 HAVING d < '2012-01-31' AND d > '2012-01-01' .

正确的查询如下:

SET @date = '2012-01-01';
SELECT @date := date_add(@date, interval 1 day) as d
FROM t
WHERE date_add(@date, interval 1 day) < '2012-01-31'
ORDER BY d
LIMIT 30;

请注意 HAVING子句应该与聚合函数一起使用,并且在没有 ORDER BY 的情况下使用 LIMIT子句可能会给您带来错误顺序的结果。

关于mysql - SELECT 在 MySQL 上的奇怪行为,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23584697/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com