MySQL 8.0不支持COUNT() OVER (ORDER BY ... RANGE BETWEEN ...)，仅支持ROWS模式，无法原生实现基于时间范围的滑动窗口统计；需用自连接+时间条件模拟，并确保created_at字段有索引。
MySQL 8.0不支持COUNT() OVER (ORDER BY ... RANGE BETWEEN ...)
直接回答核心问题：MySQL 8.0 的 COUNT() 窗口函数**无法原生实现基于时间范围的滑动窗口统计**（比如“过去7天内的订单数”）。它只支持 ROWS 模式，不支持 RANGE 模式下对 DATETIME 或 DATE 类型做区间计算。你如果写了 RANGE BETWEEN INTERVAL 7 DAY PRECEDING AND CURRENT ROW，MySQL 会报错：ERROR 3586 (HY000): Window 'w' with RANGE frame is not supported for aggregate function COUNT。
替代方案：用自连接 + 时间条件模拟滑动时间窗口
这是最常用、兼容性最好、语义最清晰的做法。核心思路是把当前行当作锚点，通过 JOIN 找出所有满足时间偏移条件的行，再聚合计数。
- 假设表叫
orders，有字段order_id、created_at（DATETIME类型） - 要统计“每个订单创建时刻起，往前推30天内（含当天）的订单总数”，可写：
SELECT o1.order_id, o1.created_at, COUNT(o2.order_id) AS cnt_30d FROM orders o1 LEFT JOIN orders o2 ON o2.created_at >= o1.created_at - INTERVAL 30 DAY AND o2.created_at <= o1.created_at GROUP BY o1.order_id, o1.created_at ORDER BY o1.created_at;
注意：LEFT JOIN 保证即使没有匹配行，COUNT() 也返回 0；GROUP BY 必须包含所有非聚合字段。
性能关键：必须给时间字段加索引
上面的自连接在大数据量下极易变慢，因为每次都要扫描匹配的时间区间。没有索引时可能全表扫描 N² 次。
- 务必在
created_at字段上建索引：CREATE INDEX idx_created_at ON orders(created_at); - 如果查询还常带用户ID过滤（如按用户统计），考虑联合索引：
CREATE INDEX idx_user_created ON orders(user_id, created_at); - 避免在
ON条件里对字段做函数操作（如DATE(created_at)），否则索引失效
更复杂的滑动窗口？用 CTE + 变量或应用层补足
如果窗口逻辑涉及多条件（比如“过去30天内、状态为completed、且金额>100的订单数”），自连接仍适用，但 ON 条件会变长，可读性下降。此时建议：
- 先用 CTE 过滤出有效行：
WITH valid_orders AS (SELECT * FROM orders WHERE status = 'completed' AND amount > 100)，再在 CTE 上做自连接 - 若窗口需动态参数（如不同用户不同天数），MySQL 8.0 不支持窗口函数的动态帧大小，只能靠应用层循环或预生成参数表
- 极端复杂场景（如嵌套时间窗口、多级聚合），别硬扛在 SQL 层，导出到 Python/Pandas 做
rolling().count()更稳
真正容易被忽略的是时间精度陷阱：MySQL 的 INTERVAL 计算基于日期/时间值本身，不是日历日。比如 2024-03-01 23:59:59 - INTERVAL 1 DAY 得到的是 2024-02-29 23:59:59，不是简单截断到 00:00 —— 如果业务要求“自然日窗口”，得先用 DATE(created_at) 归一化，再参与计算。
