Question

一遍又一遍地进行了测试，但在日期比较中却失败了。（item.id_type似乎工作正常）。

request.date的数据类型为DATETIME。

SELECT request.id, request.date, request.total_price,
    item.cod_GERFIP,item.price,item.name,request_item.quantity,
    section.name AS section,user.firstname,user.lastname   

FROM ((((`request_item` 
INNER JOIN `request` ON  request_item.id_request = request.id)
INNER JOIN `item` ON request_item.id_item = item.cod_GERFIP)
INNER JOIN `user` ON request.id_user = user.id) 
INNER JOIN `section` ON user.section = section.id) 

WHERE request.date >= '2019-01-09' AND request.date <= '2019-01-10'  
    AND item.id_type = '1' 
ORDER BY request.date DESC

Answer 1

一个猜测，因为您没有解释查询失败的方式或方式，但是在我看来，这种情况看起来并不正确：

https://skatia.github.io/ui-asset-agm

当使用这样的条件作为范围的一部分时，它会包含日期时间字段的日期部分为request.date <= '2019-01-10'的所有记录，这是一个常见的错误。也就是说，如果我们在同一天（2019-01-10）的下午1点数据库中有一个示例值，则期望该值将缩小以匹配查询中的2019-01-10 13:00:00文字，这两个值相等，所以它将满足条件。

它确实以这种方式工作。

相反，查询中的2019-01-10文字被扩大到一个完整的DateTime，看起来更像这样：2019-01-10。现在，将表中的1 PM值与此完整的日期时间进行比较，它将使条件失效。

更常见的是，日期范围使用将来一天的排他性上限集进行比较：

2019-01-10 00:00:00.000

或者，您可能会这样做：

request.date < '2019-01-11'

它甚至在大多数时间都可以使用。请注意，在（很少）of秒的情况下，您仍然可能以这种方式得到错误的结果。

您可能还会想这样做：

request.date <= '2019-01-10 23:59:59.999'

此方法有效，但不建议这样做，因为它会阻止使用您可能在convert(date,request.date) <= '2019-01-10'字段上使用的任何索引，并且这会降低数据库性能的核心。

或者问题可能更简单。随着范围从request.date开始，也许您想获取整整一天的记录，而惊讶地看到2019-01-09午夜的一些值。同样，解决方案是您要在范围的顶部设置排他性边界：

2010-01-10

作为对该问题的完整注释，我很遗憾SQL request.date < '2019-01-10'运算符在范围的两端都包含在内。这对于数字或字符串数据可能是有意义的，但对于为BETWEEN运算符定义排他上限的日期值来说，它会更有意义。

我的SQL中存在日期和日期时间比较问题

1 个答案: