lag()比关联子查询更靠谱，因其单次扫描完成所有偏移计算，避免每行触发独立查询导致的指数级性能恶化；而关联子查询在10万行表中可能引发10万次全表扫描，执行计划混乱且易拖垮生产库。
为什么直接用 LAG() 比相关子查询更靠谱
相关子查询做跨行差值，本质上是在每行执行一次独立查询，性能随数据量指数级恶化。比如 10 万行表，可能触发 10 万次全表扫描。而 LAG() 是窗口函数，单次扫描完成所有偏移计算，执行计划干净、可预测。
除非你用的是 MySQL 5.7 或更老版本（不支持窗口函数），否则别硬上相关子查询——不是不能写，是容易在生产环境拖垮数据库。
SELECT 中嵌套相关子查询怎么写才不出错
核心约束：子查询必须返回**至多一行一列**，且需用外部查询的字段做关联。常见错误是漏掉 WHERE 中的行定位条件，导致多行返回或 NULL 差值。
- 必须用主键或唯一时间戳对齐“上一行”，例如：
WHERE t2.timestamp - MySQL 8.0+ 要加
ORDER BY+LIMIT 1，否则报错；PostgreSQL 允许OFFSET 0 LIMIT 1，但语义更清晰 - 差值结果会出现首行
NULL（无前一行），需用COALESCE()或IFNULL()处理
示例（MySQL）：
SELECT
t1.id,
t1.value,
t1.value - (
SELECT t2.value
FROM data_table t2
WHERE t2.timestamp <h3>相关子查询 vs 窗口函数的兼容性陷阱</h3><p>不同数据库对相关子查询的语法容忍度差异极大。PostgreSQL 允许在 <code>SELECT</code> 里写几乎任意子查询；SQL Server 要求子查询加括号且不能含 <code>ORDER BY</code>（除非配 <code>TOP</code>）；Oracle 的 <code>ROWNUM</code> 机制会让 <code>ORDER BY</code> + <code>ROWNUM</code> 组合行为反直觉。</p>
- MySQL 5.7 不支持窗口函数，但相关子查询性能极差，建议升级或改用自连接
- SQLite 3.25+ 支持
LAG()，但旧版只能靠相关子查询，务必加索引加速timestamp字段 - 如果表没时间戳/序号字段，相关子查询无法可靠定义“上一行”，此时强行实现会依赖未定义排序，结果不可复现
真正要动手时，先检查三件事
别急着写子查询。先确认：
- 目标数据库版本是否支持
LAG()（查SELECT VERSION()或文档） -
ORDER BY字段是否有索引（特别是用于定位“上一行”的时间或序列字段） - 业务是否允许首行差值为
NULL——有些报表系统会把NULL当 0 处理，导致累计误差
相关子查询不是技术难点，而是性能和可维护性的定时炸弹。能绕开就绕开，绕不开时，至少让索引扛住它。
