如何按小时或 10 分钟对时间进行分组?
就像我做的那样
SELECT [Date]
FROM [FRIIB].[dbo].[ArchiveAnalog]
GROUP BY [Date]
我怎样才能指定小组时间?我正在使用 MS SQL 2008。
我已经尝试过使用 % 10
和 / 10
。
SELECT MIN([Date]) AS RecT, AVG(Value)
FROM [FRIIB].[dbo].[ArchiveAnalog]
GROUP BY (DATEPART(MINUTE, [Date]) / 10)
ORDER BY RecT
是否可以使日期输出没有毫秒?
Like when I do
SELECT [Date]
FROM [FRIIB].[dbo].[ArchiveAnalog]
GROUP BY [Date]
How can I specify the group period? I'm using MS SQL 2008.
I've tried this, both with % 10
and / 10
.
SELECT MIN([Date]) AS RecT, AVG(Value)
FROM [FRIIB].[dbo].[ArchiveAnalog]
GROUP BY (DATEPART(MINUTE, [Date]) / 10)
ORDER BY RecT
Is it possible to make Date output without milliseconds?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(18)
终于完成了
finally done with
简短而温馨
,对 Derek 的回答表示衷心的感谢,它1构成了本文的核心。 如果您使用的是 SQL Server 2022+,请直接访问Martin 的回答。
实际使用
详细信息和额外注释
Bin 间隔大小
MINUTE
和10
术语可以更改为任何DATEPART
和整数,2< /sup> 分别分组为不同的时间间隔。例如,10
和MINUTE
表示十分钟间隔;6
与HOUR
是六个小时的间隔。如果您多次更改间隔,则将其声明为变量可能会受益。
值类型
分组的实际值是一组距
2000-01-01 00:00
的相对偏移量。这意味着长时间间隔的数据源是可以的。其他一些答案在年份之间存在冲突。将
GROUP BY
表达式乘以间隔大小并将其包装在DATEADD
调用中将返回一个DATETIME
值。 将其包含在SELECT
语句中将为您的输出提供带有截断时间戳的单列。请参阅上面的“实际用法”示例。移动 bin 间隔的标签
DATEDIFF
之后的除法 (/
) 运算将值截断为整数(FLOOR
快捷方式),从而产生 <SELECT
输出中每行的时间间隔的开始时间。如果您想用其间隔的中间或结束来标记每一行,您可以使用以下命令调整
DATEADD
第二项中的划分下表中粗体部分:…) / 10 * 10
+ 10
, '2000' )
…) / 10 * 10
+ (10 / 2.0)
, '2000')
如果您想向内舍入间隔,使每个时间戳代表其之前的一半间隔和之后的一半间隔,请使用类似以下内容:
注意
1.
来执行未截断的操作部门代替。您需要修改GROUP BY
以进行匹配,并且您可能需要使用整个ROUND(…)
表达式以避免任何意外的浮点舍入。日期数学小知识
'2000'
是一个“锚定日期”,SQL 将围绕该日期执行日期数学。大多数示例代码使用0
作为锚点,但是 JereonH 发现您在以下情况下遇到整数溢出:按秒或毫秒对最近的日期进行分组。3如果您的数据跨越几个世纪,4在
GROUP BY
中使用单个锚定日期来表示秒否则毫秒仍然会遇到溢出。对于这些查询,您可以要求每一行将分箱比较锚定到其自己日期的午夜。使用这两个替换之一来代替查询中出现的
'2000'
:DATEADD(DAY, DATEDIFF(DAY, 0, aa.[date]), 0)
CONVERT(DATETIME, CONVERT(DATE, aa.[date]))
您的查询将完全不可读,但它会起作用。
1 在发布几年后我意识到我的代码可以简化为几乎与德里克的回答。
2 如果您希望所有
:00
时间戳都符合分箱条件,请使用您的DATEPART
的最大值可以均匀划分为。5 作为反例,将结果分组为 13 分钟或 37 小时的 bin 将跳过一些:00
,但是 它应该仍然可以正常工作。3 数学表示 232 ≈ 4.29E+9。这意味着对于
SECOND
的DATEPART
,两边各有 43 亿秒,相当于“锚定日期 ± 136 年”。同样,232 毫秒约为 49.7 天。4 如果您的数据实际上跨越了几个世纪或几千年,并且仍然精确到秒或毫秒......恭喜!无论你在做什么,继续做下去。
5 如果您想知道为什么我们的时钟顶部有一个 12,请思考5是6(12的一半)或以下的唯一整数不是 12 的因数。然后请注意 5 × 12 = 60。对于包含小时、分钟和秒的 bin 大小,您有很多选择。
Short and sweet
With heavy acknowledgements to Derek's answer, which1 forms the core of this one. If you're on SQL Server 2022+, go straight to Martin's answer.
Practical usage
Details and extra commentary
Bin interval size
The
MINUTE
and10
terms can be changed to anyDATEPART
and integer,2 respectively, to group into different time intervals. For example,10
withMINUTE
is ten minute intervals;6
withHOUR
is six hour intervals.If you change the interval a lot, you might benefit from declaring it as a variable.
Value type
The actual values being grouped are a set of relative offsets from
2000-01-01 00:00
. This means data sources over long time intervals are fine. Some other answers have collision between years.Multiplying the
GROUP BY
expression by the interval size and wrapping it in aDATEADD
invocation will return you aDATETIME
value. Including it in theSELECT
statement will give your output a single column with the truncated timestamp. See the "Practical Usage" example above.Shifting the label for the bin interval
The division (
/
) operation afterDATEDIFF
truncates values to integers (aFLOOR
shortcut), which yields the beginning of time intervals for each row in yourSELECT
output.If you want to label each row with the middle or end of its interval, you can tweak the division in the second term of
DATEADD
with the bold part in the table below:…) / 10 * 10
+ 10
, '2000')
…) / 10 * 10
+ (10 / 2.0)
, '2000')
If you want to round your intervals inward such that each timestamp represents half an interval before and half an interval after it, use something like this:
Note the
1.
to do untruncated division instead. You will need to modify yourGROUP BY
to match, and you may want to use the wholeROUND(…)
expression to avoid any unexpected float rounding.Date math trivia
'2000'
is an "anchor date" around which SQL will perform the date math. Most sample code uses0
for the anchor, but JereonH discovered that you encounter an integer overflow when grouping more-recent dates by seconds or milliseconds.3If your data spans centuries,4 using a single anchor date in the
GROUP BY
for seconds or milliseconds will still encounter the overflow. For those queries, you can ask each row to anchor the binning comparison to its own date's midnight.Use one of the two replacements instead of
'2000'
wherever it appears in the query:DATEADD(DAY, DATEDIFF(DAY, 0, aa.[date]), 0)
CONVERT(DATETIME, CONVERT(DATE, aa.[date]))
Your query will be totally unreadable, but it will work.
1 I realized several years after posting that my code could be simplified to nearly the same as Derek's answer.
2 If you want all
:00
timestamps to be eligible for binning, use an integer that yourDATEPART
's maximum can evenly divide into.5 As a counterexample, grouping results into 13-minute or 37-hour bins will skip some:00
s, but it should still work fine.3 The math says 232 ≈ 4.29E+9. This means for a
DATEPART
ofSECOND
, you get 4.3 billion seconds on either side, which works out to "anchor date ± 136 years." Similarly, 232 milliseconds is ≈ 49.7 days.4 If your data actually spans centuries or millenia and is still accurate to the second or millisecond… congratulations! Whatever you're doing, keep doing it.
5 If you ever wondered why our clocks have a 12 at the top, reflect on how 5 is the only integer from 6 (half of 12) or below that is not a factor of 12. Then note that 5 × 12 = 60. You have lots of choices for bin sizes with hours, minutes, and seconds.
在 T-SQL 中,您可以:
或者
按分钟使用
DATEPART(mi, [Date])
或
按 10 分钟使用
DATEPART(mi, [Date]) / 10
(例如蒂莫西建议)In T-SQL you can:
or
by minute use
DATEPART(mi, [Date])
or
by 10 minutes use
DATEPART(mi, [Date]) / 10
(like Timothy suggested)对于 10 分钟的间隔,您可以
像 tzup 和 Pieter888 已经提到的那样...进行一个小时的间隔,只需
For a 10 minute interval, you would
As was already mentioned by tzup and Pieter888... to do an hour interval, just
作者给出的原始答案效果很好。为了扩展这个想法,你可以做类似的事情
,这样你就可以按比 60 分钟更长的时间段进行分组,比如 720,即半天等。
The original answer the author gave works pretty well. Just to extend this idea, you can do something like
which will allow you to group by a longer period then 60 minutes, say 720, which is half a day etc.
应该是这样的
(对语法不是 100% 确定 - 我更像是 Oracle 类型的人)
在 Oracle 中:
Should be something like
(Not 100% sure about the syntax - I'm more an Oracle kind of guy)
In Oracle:
对于 MySQL:
For MySql:
对于 SQL Server 2022+ 的用户,现在有一个专用的
DATE_BUCKET
函数可以满足此需求。使用示例
如果基础列已编入索引,则也可以是 相当高效
For people on SQL Server 2022+ there is now a dedicated
DATE_BUCKET
function that addresses this need.Example usage
If the underlying column is indexed this can also be pretty efficient
如果您想实际显示日期,请使用变量分组,并能够指定大于 60 分钟的时间范围:
If you want to actually display the date, have a variable grouping, and be able to specify larger time frames than 60 minutes:
在 SQLite 中,为了按小时分组,您可以执行以下操作:
并按每 10 分钟分组:
In SQLite, in order to group by hour, you can do:
and to group by each 10 minutes:
我的解决方案是使用函数创建一个包含日期间隔的表,然后将该表连接到我想要使用表中的日期间隔进行分组的数据。
然后在呈现数据时可以轻松选择日期间隔。
My solution is to use a function to create a table with the date intervals and then join this table to the data I want to group using the date interval in the table.
The date interval can then be easily selected when presenting the data.
对于 SQL Server 2012,虽然我相信它可以在 SQL Server 2008R2 中工作,但我使用以下方法将时间切片降低到毫秒:
其工作原理是:
@ms = DATEDIFF(MILLISECOND, CAST(time AS DATE), time)
@rms = @ms % @msPerSlice
code>DATEADD(MILLISECOND, -@rms, time)
不幸的是,由于微秒和更小的单位会溢出,因此,更大、更精细的数据集需要使用不太方便的定点。
我没有对此进行严格的基准测试,而且我也不从事大数据工作,因此您的里程可能会有所不同,但性能并没有比在我们的设备和数据集上尝试的其他方法明显差,而且开发人员可以方便地进行任意切片,这使得它值得对于我们来说。
For SQL Server 2012, though I believe it would work in SQL Server 2008R2, I use the following approach to get time slicing down to the millisecond:
This works by:
@ms = DATEDIFF(MILLISECOND, CAST(time AS DATE), time)
@rms = @ms % @msPerSlice
DATEADD(MILLISECOND, -@rms, time)
Unfortunately, as is this overflows with microseconds and smaller units, so larger, finer data sets would need to use a less convenient fixed point.
I have not rigorously benchmarked this and I am not in big data, so your mileage may vary, but performance was not noticeably worse than the other methods tried on our equipment and data sets, and the payout in developer convenience for arbitrary slicing makes it worthwhile for us.
将两个 600 替换为您想要分组的任意秒数。
如果您经常需要此操作并且表不会更改,正如名称 Archive 所暗示的那样,将日期(和时间)转换并存储为表中的 unixtime 可能会更快一些。
replace the two 600 by any number of seconds you want to group.
If you need this often and the table doesn't change, as the name Archive suggests, it would probably be a bit faster to convert and store the date (& time) as a unixtime in the table.
我知道我在这个节目上迟到了,但我使用了这个 - 非常简单的方法。这样您就可以获得 60 分钟的切片,而不会出现任何舍入问题。
I know I am late to the show with this one, but I used this - pretty simple approach. This allows you to get the 60 minute slices without any rounding issues.
尝试这个查询。它构成一列。 (参考@nobilist的回答)
Try this query. It makes one column. (references @nobilist answer)
以下选项提供了该时间间隔的人类可读的开始时间(7:30、7:40 等)。
在临时表中,它使用 SMALLDATETIME 截断秒和毫秒,然后主查询减去所需分钟间隔内的任何数量。
也可以用一行代码完成,但可读性较差。
Here is an option that provides a human readable start time of that interval (7:30, 7:40, etc).
In a temp table, it truncates seconds and milliseconds by using SMALLDATETIME, and then the main query subtracts any amount over the desired minute interval.
It can also be done in a single line of code, but it is not as readable.