如何在 SQL 的 where
子句中选择 12/20/2008?
服务器是 SQL Server 2005。
select * from tblErrorLog
where errorDate = '12/20/2008'
如何在 SQL 的 where
子句中选择 12/20/2008?
服务器是 SQL Server 2005。
select * from tblErrorLog
where errorDate = '12/20/2008'
WHERE datetime_column >= '20081220 00:00:00.000'
AND datetime_column < '20081221 00:00:00.000'
yyyy-MM-dd
格式在大多数情况下确实有效,但并非所有情况都适用。 @onupdatecascade: 你说得对。我已经更新了我的答案,使用了一个在所有情况下都安全的格式。 - LukeH首先,我建议使用ISO-8601标准格式的日期/时间 - 它可以在SQL Server上不考虑语言和区域设置的情况下工作。ISO-8601是YYYYMMDD
格式 - 没有空格,没有破折号 - 只有数据:
select * from tblErrorLog
where errorDate = '20081220'
其次,你需要知道SQL Server 2005 DATETIME
类型始终包含时间。如果你只检查日期部分的完全匹配,你将仅得到与时间为0:00:00匹配的行 - 没有其他内容。
你可以使用推荐的任何范围查询之一,或在SQL Server 2008中使用DATE
日期时间 - 或者你可以执行类似于以下的检查:
select * from tblErrorLog
where DAY(errorDate) = 20 AND MONTH(errorDate) = 12 AND YEAR(errorDate) = 2008
哪种方法对您来说最好,就使用哪种。
如果您需要经常执行此查询,您可以尝试规范化DATETIME
以仅包含日期,或者您可以添加计算列用于DAY、MONTH和YEAR:
ALTER TABLE tblErrorLog
ADD ErrorDay AS DAY(ErrorDate) PERSISTED
ALTER TABLE tblErrorLog
ADD ErrorMonth AS MONTH(ErrorDate) PERSISTED
ALTER TABLE tblErrorLog
ADD ErrorYear AS YEAR(ErrorDate) PERSISTED
然后你可以更轻松地查询:
select * from tblErrorLog
where ErrorMonth = 5 AND ErrorYear = 2009
等等,因为这些字段是计算和持续的,所以它们始终是最新和最新的,并且由于它们是持久化的,如果需要,甚至可以对它们进行索引。
DATETIME
数据类型,这仍然有效。如果您使用的是较新的数据类型,如 DATE
或 DATETIME2(n)
,它们对格式要求不那么严格,您绝对可以使用“-”作为分隔符。 - marc_s你没有说明你使用的是哪个数据库,但在MS SQL Server中,可以这样实现:
WHERE DateField = {d '2008-12-20'}
如果它是一个时间戳字段,那么你需要一个范围:
WHERE DateField BETWEEN {ts '2008-12-20 00:00:00'} AND {ts '2008-12-20 23:59:59'}
errorDate BETWEEN '12/20/2008' AND '12/21/2008'
我对于这样的时间范围,偏好的方法是:
'20081220' <= errorDate AND errordate < '20081221'
可以处理常见的索引(范围扫描、可搜索谓词、无函数)并正确截断下一天的午夜时间,而不依赖于SQL Server的时间粒度(例如23:59:59.997)。
Select * from tblErrorLog where convert(date,errorDate,101) = '12/20/2008'
请参阅CAST和CONVERT以获取更多信息。
select * from tblErrorLog
where errorDate BETWEEN '12/20/2008' AND DATEADD(DAY, 1, '12/20/2008')
/****** Script for SelectTopNRows command from SSMS ******/
SELECT *
FROM [dbo].[PublishedInfo]
where PublishedDate >= '2022-02-14T11:31:16.5299166+00:00'