子查询不能直接用 LIMIT/TOP 做滑动窗口，因SQL标准限制：MySQL 8.0前不支持、SQL Server的TOP需ORDER BY且不可用于派生表、Oracle的ROWNUM易失效；应改用ROW_NUMBER() OVER (ORDER BY ts DESC)加外层过滤。
子查询不能直接用 LIMIT/TOP 做滑动窗口？
SQL 标准里，LIMIT、TOP、ROWNUM 这类分页/截断语法在子查询中普遍受限——MySQL 8.0 前不支持子查询带 LIMIT，SQL Server 的 TOP 在子查询中需配合 ORDER BY 且不可用于派生表，Oracle 的 ROWNUM 在 WHERE 中写错位置就全失效。这不是你写错了，是语法层级限制。
真正能跨数据库稳定实现“取最近 N 条记录做聚合”的方式，是用窗口函数替代子查询截断逻辑：
- 用
ROW_NUMBER() OVER (ORDER BY ts DESC)给每行打序号，再在外层过滤rn ，等效于“最近 5 条” - 若需按用户分组滚动（如每个 user_id 独立算最近 5 条），必须加
PARTITION BY user_id - 注意
ORDER BY必须明确、确定（避免时间字段重复时序混乱），必要时追加主键去重：ORDER BY ts DESC, id DESC
MySQL 5.7 怎么绕过无窗口函数的限制？
MySQL 5.7 不支持 ROW_NUMBER()，但可以用变量模拟序号生成。关键不是“能不能”，而是“怎么保证顺序不崩”：
- 必须用
ORDER BY显式排序后，再用变量赋值，否则执行计划可能跳过排序直接赋值，序号全乱 - 变量初始化要放在同一语句中，别用
SET @rn := 0分开执行，某些客户端会丢变量状态 - 示例：查每个订单的最近 3 笔支付流水均值
SELECT order_id, AVG(amount) AS avg_recent_3
FROM (
SELECT order_id, amount,
@rn := IF(@prev = order_id, @rn + 1, 1) AS rn,
@prev := order_id
FROM payments
CROSS JOIN (SELECT @rn := 0, @prev := '') AS _
ORDER BY order_id, created_at DESC
) t
WHERE rn <= 3
GROUP BY order_id;
WHERE 子句里写子查询做“动态 N”会慢出天际？
如果把滑动窗口大小（比如 N=7 天 or N=10 条）做成子查询参数，例如 WHERE id IN (SELECT id FROM ... ORDER BY ts DESC LIMIT ?)，多数引擎无法下推优化，会导致外层扫描全表再关联。实际性能取决于两点：
- 子查询是否能走索引：确保
ORDER BY字段有复合索引，如(user_id, ts)而非单列ts - 避免在子查询里做聚合或 JOIN：先
SELECT id拿主键，再用主键回表，比直接SELECT *快得多 - PostgreSQL 可用
LATERAL把子查询转成关联，MySQL 8.0+ 可用WITH RECURSIVE模拟，但别硬套——简单场景优先用窗口函数
滑动窗口结果和业务时间对不上？
最常被忽略的是时区与数据延迟问题：窗口计算用的是数据库服务器时间，但业务事件时间（event_time）可能是应用端生成、带时区偏移，或者 Kafka 写入有 lag。一旦 ORDER BY event_time 和真实发生顺序错位，窗口统计就失真。
务必确认：
- 所有时间字段统一用
TIMESTAMP WITH TIME ZONE（PostgreSQL）或datetime+ 显式时区转换（MySQL） - ETL 链路中是否有延迟缓冲？比如日志采集延迟 2 分钟，那“最近 5 分钟”窗口实际漏掉最新数据
- 测试时别只查历史数据，用
NOW()或CURRENT_TIMESTAMP动态构造测试用例，验证实时性
窗口函数本身很稳，但输入数据的时间可信度，才是滑动窗口统计真正的地基。
