mysql 5.7及更早版本不支持在嵌套查询中直接使用窗口函数（如lag、row_number），因其解析器未实现窗口函数语法与执行模块，必须用用户变量模拟并严格保证order by和单select内初始化赋值。
嵌套查询里不能直接用窗口函数做时间差分组？
不能。像 LAG()、ROW_NUMBER() 这类窗口函数在子查询（尤其是非相关子查询）中不可用，MySQL 5.7 及更早版本、SQL Server 某些旧版本都会报错 Window function is not allowed in this context。必须把带窗口函数的逻辑放在最外层或 CTE 中——但 CTE 不是所有数据库都支持（比如 SQLite 3.8 之前、老版 MySQL），所以得先确认你的环境。
实操建议：
- MySQL 8.0+、PostgreSQL、SQL Server 2016+：优先用 CTE + 窗口函数，逻辑清晰且可读性强
- MySQL 5.7 或更老版本：改用变量模拟行号，例如
@row := @row + 1，但要注意执行顺序依赖ORDER BY，且不能在子查询里初始化变量 - 如果只是算「上一条记录的时间差」，可用相关子查询替代，但性能随数据量下降明显（O(n²)）
怎么用相关子查询计算不规则时间间隔？
核心思路是：对当前行，查出「时间小于它且最接近它的那条记录」，再做减法。适用于小表（timestamp 字段。
示例（计算每条记录距前一次操作的分钟数）：
SELECT
id,
event_time,
TIMESTAMPDIFF(MINUTE,
(SELECT MAX(event_time)
FROM logs l2
WHERE l2.event_time <p>注意点：</p>
- 必须给
event_time建索引，否则子查询全表扫描，10万行可能秒变分钟级响应 -
MAX(event_time)保证只取一个值；用LIMIT 1在子查询里会报错（MySQL 不允许子查询含 LIMIT） - 第一条记录结果为
NULL，因为找不到更早时间——这是正常行为，不是 bug
遇到“时间跳跃”需要分段统计怎么办？
比如定义「间隔 > 30 分钟就算新会话」，这时不能只算前后差，得先标记会话 ID，再按会话聚合。嵌套查询本身不擅长状态传递，硬写容易漏逻辑分支。
推荐拆成两步：
- 第一层子查询：用变量或 CTE 给每行打上
session_id（判断event_time - prev_time > 1800就递增） - 第二层：按
session_id分组，用MIN(event_time)和MAX(event_time)算持续时间
MySQL 5.7 示例（变量方式）：
SELECT
session_id,
MIN(event_time) AS start_time,
MAX(event_time) AS end_time,
TIMESTAMPDIFF(SECOND, MIN(event_time), MAX(event_time)) AS duration_sec
FROM (
SELECT
id, event_time,
@session := IF(TIMESTAMPDIFF(SECOND, @prev, event_time) > 1800, @session + 1, @session) AS session_id,
@prev := event_time
FROM logs, (SELECT @session := 0, @prev := NULL) AS _
ORDER BY event_time
) AS sessioned
GROUP BY session_id;
关键细节：
- 变量初始化必须和主查询写在同一语句里，且
ORDER BY不可少，否则分组错乱 - 别在视图或存储过程中复用这个变量逻辑——MySQL 变量作用域不保证稳定
- PostgreSQL 用户请直接用
LAG()+SUM() OVER(...)累计标记，更安全
为什么嵌套太深会导致执行计划崩溃？
三层以上嵌套（尤其含相关子查询）会让优化器放弃估算成本，直接走嵌套循环，数据量稍大就触发临时表、磁盘排序甚至超时。常见症状是执行时间从毫秒跳到几十秒，EXPLAIN 显示 type=ALL 或 Extra=Using temporary; Using filesort。
应对策略：
- 把中间结果物化：先
CREATE TEMPORARY TABLE存下带序号/会话 ID 的中间集，再查它 - 避免在
WHERE子句里调用子查询算时间差，移到SELECT或JOIN条件中 - SQLite 用户特别注意：
WITH RECURSIVE虽能解部分问题，但深度超过 1000 层默认报错，需设PRAGMA recursive_triggers = ON并调大limit_recursive
真正麻烦的从来不是语法怎么写，而是时间字段有没有索引、数据库版本支不支持 CTE、以及你是否意识到变量在并发查询里根本不可靠。
