mysql 5.7 缺乏窗口函数、递归cte等特性，时间序列分析需用while循环生成日期、left join补全、单次group by聚合，并严控边界与索引以避免性能陷阱。
MySQL 5.7 本身不支持窗口函数、递归 CTE 或原生时间序列聚合语法，做复杂时间序列分析必须靠存储过程手动构造时间点、补全缺失日期、关联业务数据并聚合——这不是“加个函数就能搞定”的事，而是得自己模拟时间轴、控制循环、处理边界。
用 WHILE + DATE_SUB 构造连续日期序列
MySQL 5.7 没有 GENERATE_SERIES，也不能用 WITH RECURSIVE（那是 8.0+ 才支持），唯一可靠方式是用变量 + WHILE 循环生成指定范围的日期。关键不是“能不能生成”，而是“怎么避免越界和性能崩塌”：
- 起始日期必须用
DATE()或STR_TO_DATE()显式转成日期类型，否则DATE_SUB(@d, INTERVAL 1 DAY)在遇到字符串时可能静默失败或返回NULL - 循环变量建议用
INT计数器（如DECLARE i INT DEFAULT 0），再用DATE_ADD(start_date, INTERVAL i DAY)算日期，比直接操作日期变量更稳定 - 别用
@date := DATE_SUB(@date, INTERVAL 1 DAY)做倒序循环——一旦@date变成NULL，后续所有DATE_SUB(NULL, ...)都返回NULL，循环就卡死在NULL上 - 生成超过 366 天的序列时，务必加
IF i > 1000 THEN LEAVE loop_label; END IF;防止无限循环（线上真有因日期范围算错导致 CPU 100% 的案例）
LEFT JOIN 补全缺失日期时，临时表必须带索引
时间序列分析常要“按天统计订单数”，但原始表里某些天根本没数据。想补全就得用生成的日期序列 LEFT JOIN 业务表。这时最容易被忽略的是性能陷阱：
- 临时表（比如
tmp_dates）如果只靠AUTO_INCREMENT主键，JOIN时仍可能走全表扫描——必须对日期字段加INDEX，哪怕它是临时表：CREATE TEMPORARY TABLE tmp_dates (dt DATE PRIMARY KEY);
-
LEFT JOIN orders ON DATE(orders.order_time) = tmp_dates.dt这种写法会让orders.order_time上的索引失效；正确做法是提前把orders表建好GENERATED COLUMN（5.7 不支持）或改用order_time >= dt AND order_time ，并确保 <code>order_time有索引 - 补全后聚合前，先
TRUNCATE tmp_result再INSERT INTO ... SELECT，别用REPLACE INTO——后者会触发唯一键校验和删除重建，慢一个数量级
聚合逻辑不能塞在 IF 块里做条件累加
有人想在 WHILE 循环里逐天查订单、判断状态、更新累计值，结果写出这种结构：
IF order_status = '已支付' THEN SET paid_sum = paid_sum + amount; END IF;
这看着省事，实际错在三处：
- 每次
SELECT单天数据都要走一次磁盘 I/O，100 天就是 100 次查询，远不如一次性GROUP BY DATE(order_time)扫一遍快 -
IF块里执行SELECT ... INTO时，若当天无记录，变量不会被赋值，仍保持旧值（MySQL 不自动置NULL），导致累计值污染 - 没处理事务：中间某次
UPDATE失败，前面的SET已生效，无法回滚——必须把整个聚合逻辑包在START TRANSACTION+ 错误处理器里
正确路径是：先用单条 INSERT INTO tmp_agg SELECT DATE(order_time), COUNT(*), SUM(amount) FROM orders WHERE ... GROUP BY DATE(order_time) 落地聚合结果，再用 LEFT JOIN tmp_dates 补空，最后统一输出。
跨月/跨年边界必须显式用 LAST_DAY 和 DATE_ADD
分析“最近 N 天”简单，但要做“上个月每日销售”或“本季度每周均值”，DATE_SUB(CURDATE(), INTERVAL 1 MONTH) 会出问题：
-
DATE_SUB('2026-03-31', INTERVAL 1 MONTH)返回'2026-02-28'，不是'2026-02-31'（不存在），但如果你依赖它算“2 月第 1 天”，就偏了 - 正确方式是先定位到月份起点：
DATE_SUB(CURDATE(), INTERVAL DAYOFMONTH(CURDATE())-1 DAY)，再用LAST_DAY()拿月末，避免日期截断 - 计算周粒度时，
WEEK()函数受default_week_format影响极大，生产环境必须显式写WEEK(dt, 1)（周一为周首）或WEEK(dt, 3)（周一为周首且年度第一周含 4 天以上），不能裸用WEEK(dt)
真正麻烦的从来不是“怎么写出能跑的代码”，而是“当数据跨年、跨月、跨时区、含节假日，且要求和 BI 工具对齐时，哪一行日期计算会悄悄错一天”。这些细节不压到具体场景里反复验证，光看文档永远发现不了。
