SQL时间序列统计需严格遵循四步流程：数据清洗→时间对齐→分组聚合→结果校验；每步均影响准确性，尤以清洗和校验耗时最多、不可省略。
SQL时间序列统计不是简单套个GROUP BY就完事，关键在时间切片的准确性、时区一致性、边界处理和聚合逻辑的匹配。标准流程有四个不可跳过的环节：数据清洗→时间对齐→分组聚合→结果校验，每一步出错都会导致趋势误判或数值偏差。
一、先清洗再统计：过滤无效时间与空值
很多问题其实源于原始数据本身——比如JLSJ字段含'0000-00-00'、NULL、或超出业务范围的时间（如2099年）。不处理直接统计，会把异常值混入日/月汇总中。
- 用
WHERE JLSJ IS NOT NULL AND JLSJ >= '2020-01-01' AND JLSJ 兜底时间范围 - 对缺失值做显式填充：
COALESCE(FWIP, 'unknown')或按业务规则补默认值 - 避免用
TO_CHAR(JLSJ, 'YYYY-MM-dd')前不加非空判断——Oracle/PG中NULL转字符串会变空串，导致分组错乱
二、时间对齐要统一：别让时区和精度拖后腿
数据库存的是UTC还是本地时间？字段类型是TIMESTAMP还是DATETIME？这些决定BETWEEN和DATE_TRUNC是否真正“对齐”。例如MySQL的TIMESTAMP自动转UTC存储，而DATETIME原样保存，混用会导致跨日统计偏移8小时。
- 查清字段实际存储逻辑：
SELECT pg_typeof(JLSJ) FROM tb_lytj LIMIT 1（PG）或DESCRIBE tb_lytj（MySQL） - 统一转换到目标时区再切片：
AT TIME ZONE 'Asia/Shanghai'（PG）或CONVERT_TZ(JLSJ, '+00:00', '+08:00')（MySQL） - 避免用
DATE(JLSJ)代替TRUNC(JLSJ)——前者可能隐式四舍五入，后者才是精确截断到日
三、分组聚合按需选函数：别硬套TO_CHAR万能模板
按天/月统计确实可用TO_CHAR(JLSJ, 'YYYY-MM-dd')，但遇到“每15分钟统计”或“周一至周五单独聚合”，就得换思路。盲目套格式化函数，容易忽略时间粒度的数学本质。
- 任意分钟粒度（如30分钟）：
FLOOR(EXTRACT(EPOCH FROM JLSJ)/1800)→ 每1800秒一个桶 - 工作日统计：
EXTRACT(DOW FROM JLSJ)（PG，周日=0）或WEEKDAY(JLSJ)（MySQL，周日=6），再CASE WHEN映射 - 年初至今累计：
WHERE JLSJ BETWEEN DATE_TRUNC('YEAR', CURRENT_DATE) AND CURRENT_DATE，别用YEAR(JLSJ)=YEAR(CURDATE())——后者无法利用索引
四、结果必须校验：检查总数、边界、空桶
统计完别急着导出。常见陷阱包括：某天无数据导致该日记录消失（漏桶）、跨月最后一天被切到下月、凌晨数据因时区错位进错分组。
- 核对总记录数：
SELECT COUNT(*) FROM tb_lytj WHERE JLSJ >= '2025-12-01'vs 分组后SUM(LLS) - 补全空日期：
GENERATE_SERIES('2025-12-01'::DATE, '2025-12-12'::DATE, '1 day')左连接，确保12天都有行 - 抽查边界值：取
JLSJ = '2025-12-01 00:00:00'和'2025-12-01 23:59:59'两条，看是否归入同一天
基本上就这些。流程看着线性，实操中清洗和校验占时最多——但省掉这两步，后面所有分析都是空中楼阁。
