sql server 2022 非原生时序数据库，但可通过 time_bucket + datetime2 列索引 + where 时间过滤 + 正确 null 处理实现高效传感器聚合分析；连续聚合需手动维护汇总表。
SQL Server 2022 本身不是时序数据库，但通过 GROUP BY time_bucket + 索引优化 + 查询存储反馈，能高效支撑分钟级/小时级传感器类聚合分析。直接套用传统 AVG/MAX 语句在百万级时序表上会慢，关键在于让时间分组可下推、可跳过扫描。
time_bucket 函数必须配合 datetime2 列和索引使用
SQL Server 2022 引入了 time_bucket（需 CU14 或更高），但它不自动加速——只有当时间列是 datetime2 类型、且该列上有 B-tree 索引（最好是包含索引）时，查询优化器才能利用索引跳过无效分区。
-
time_bucket的第一个参数必须是datetime2，不能是datetime或字符串； - 若时间列名为
ts，建索引语句应为：CREATE INDEX IX_sensor_ts ON sensor_data(ts) INCLUDE (value, device_id); - 错误写法：
SELECT time_bucket('5 minutes', CAST(ts AS varchar))—— 强制转换导致索引失效； - 正确写法：
SELECT time_bucket('5 minutes', ts) AS bucket, AVG(value) FROM sensor_data WHERE ts >= '2026-10-10' GROUP BY time_bucket('5 minutes', ts);
聚合前加 WHERE 时间范围过滤不可省略
即使建了索引，GROUP BY time_bucket 若没配 WHERE，SQL Server 仍可能执行全表扫描。优化器不会自动推导“只查最近7天”这种业务逻辑。
- 必须显式写
WHERE ts >= DATEADD(day, -7, GETUTCDATE())，不能依赖应用层裁剪； - 避免用函数包裹索引列：
WHERE DATEPART(hour, ts) = 14会禁用索引； - 若常用固定周期（如每小时汇总），可提前建计算列：
ALTER TABLE sensor_data ADD hour_bucket AS DATEADD(hour, DATEDIFF(hour, 0, ts), 0) PERSISTED;，再对它建索引； - 注意：时区敏感操作（如
AT TIME ZONE）会阻止索引查找，建议统一存 UTC，应用层转时区。
避免 COUNT(*) 和 NULL 值混用导致结果偏差
传感器数据常有大量 NULL（如离线设备上报空值），而 COUNT(*) 统计的是行数，COUNT(value) 才统计有效读数——两者差几倍很常见。
- 求“每5分钟有多少条有效温度记录”：用
COUNT(temperature)； - 求“每5分钟共产生多少条原始上报”：用
COUNT(*)； -
AVG(temperature)自动忽略 NULL，但若整块窗口全是 NULL，结果就是NULL，不是 0——下游程序需处理这个空值； - 想把 NULL 当 0 参与平均？得显式写：
AVG(ISNULL(temperature, 0))，但语义已变，慎用。
连续聚合（Continuous Aggregate）在 SQL Server 中不存在，得靠物化视图或作业模拟
像 TimescaleDB 的 create_continuous_aggregate 或 InfluxDB 的 retention policy，在 SQL Server 2022 中没有原生等价功能。你得自己维护聚合表。
- 推荐方案：用
CREATE OR ALTER VIEW封装常用聚合逻辑，再搭配查询存储（Query Store）识别高频慢查询，针对性加索引； - 若需亚秒级响应，可建每日/每小时汇总表，用
sp_add_schedule+sp_add_job定时刷新（例如每10分钟跑一次INSERT INTO sensor_hourly ... SELECT time_bucket('1 hour', ts), AVG(value), COUNT(*) ...）； - 别用触发器实时更新聚合表——高写入场景下极易锁表；
- 注意：SQL Server 的物化视图叫“索引视图”，但要求严格（
SCHEMABINDING、所有列明确、不能有GETDATE()等），且time_bucket不被支持，所以无法用于时序窗口。
真正卡顿的点往往不在聚合函数本身，而在时间列是否可 Seek、WHERE 条件是否可下推、以及 NULL 处理是否符合业务预期——这三个地方错一个，QPS 就可能掉一个数量级。
