SQL时间序列统计核心在于按粒度对齐时间而非简单过滤，关键包括自然日聚合（用DATE()+范围查询防索引失效）、15分钟桶（时间戳转秒后向下取整）、同比环比（双表关联或LAG函数）、YTD/近7天动态区间（避免硬编码）。
SQL时间序列统计的核心是把时间字段变成可分组、可对齐、可滚动的维度，而不是简单过滤。关键不在“算什么”，而在“按什么粒度对齐时间”——比如按天、按小时、按15分钟桶，甚至按工作日/自然周对齐。
按自然日聚合订单量和销售额
最常见需求：看每天多少单、卖了多少钱。用DATE()提取日期部分，避免函数作用在字段上导致索引失效：
-
推荐写法（索引友好）：
WHERE order_time >= '2025-12-01' AND order_time < '2025-12-02'，再GROUP BY DATE(order_time) -
不推荐写法：
WHERE YEAR(order_time)=2025 AND MONTH(order_time)=12—— 会跳过索引，全表扫描 - 示例查询：
SELECT DATE(order_time) AS dt, COUNT(*) AS cnt, SUM(order_amount) AS amt FROM orders GROUP BY DATE(order_time) ORDER BY dt;
按固定时间窗口做分钟级汇总（如15分钟桶）
适合监控类场景，比如API调用量、设备上报频次。核心是把时间“向下取整”到最近的窗口起点：
- 原理：用
EXTRACT(EPOCH FROM ts)转为秒数 → 减去时区偏移（如东八区减8×3600）→ 除以900（15分钟=900秒）→FLOOR()→ 再乘回去还原时间戳 - PostgreSQL示例：
SELECT to_timestamp(FLOOR((EXTRACT(EPOCH FROM event_time) - 8*3600) / 900) * 900) AS bucket_15m, COUNT(*) FROM sensor_log GROUP BY bucket_15m ORDER BY bucket_15m; - MySQL可用
UNIX_TIMESTAMP()和FLOOR((UNIX_TIMESTAMP(t)-28800)/900)实现类似逻辑
同比/环比对比：当前月 vs 上月 or 今年 vs 去年
不能只靠WHERE，得用派生表或窗口函数拉出多期数据并排比较：
- 简单双表关联法（清晰易懂）：
SELECT cur.mon, cur.cnt AS cur_cnt, last.cnt AS last_cnt, ROUND((cur.cnt-last.cnt)/NULLIF(last.cnt,0),3) AS mom_rate FROM (SELECT DATE_FORMAT(order_time,'%Y-%m') mon, COUNT(*) cnt FROM orders WHERE order_time >= '2025-11-01' GROUP BY mon) cur JOIN (SELECT DATE_FORMAT(order_time,'%Y-%m') mon, COUNT(*) cnt FROM orders WHERE order_time >= '2025-10-01' AND order_time < '2025-11-01' GROUP BY mon) last ON cur.mon = DATE_ADD(last.mon, INTERVAL 1 MONTH); - 更灵活可用
LAG()窗口函数，一行内完成环比计算
年初至今（YTD）、近7天滚动（TTM）这类动态区间统计
重点是让时间下限随当前日期自动变化，避免硬编码：
- YTD（MySQL）：
WHERE order_time >= DATE(CONCAT(YEAR(NOW()),'-01-01'))或更稳的>= STR_TO_DATE(CONCAT(YEAR(NOW()),'-01-01'), '%Y-%m-%d') - 近7天（含今天）：
WHERE order_time >= DATE_SUB(CURDATE(), INTERVAL 6 DAY)（注意：CURDATE()不含时分秒，适合纯日期场景） - 精确到秒的近7天：
WHERE order_time >= NOW() - INTERVAL 7 DAY
基本上就这些。真正卡住人的往往不是语法，而是时间对齐逻辑没想清楚——先定好“桶怎么划”，再选函数，比死记函数名管用得多。
