未指定ORDER BY的MySQL LAG函数是否非确定性？及相关使用疑问

1. 是否存在无需指定ORDER BY即可使用LAG函数的场景？ #

几乎没有可靠的实用场景。LAG的核心作用是获取窗口内前一行的数据，但如果不指定ORDER BY，数据库无法确定“前一行”的逻辑顺序——此时返回的是分区内任意一行的数据，完全依赖数据库的存储顺序或执行计划的临时排序，结果是不可预测的。

你最初觉得结果“看似正确”只是巧合，一旦数据量变化、执行计划调整（比如添加WHERE子句后），结果就会出现异常。你遇到的“返回未过滤查询中没有的行”问题，本质是没有ORDER BY导致窗口内的行顺序完全不可控：无WHERE时数据库可能按存储顺序计算窗口，加了WHERE后执行计划可能先过滤再调整临时排序，导致LAG取到的“前一行”和之前完全不同，看起来像是出现了不存在的行，实际是结果不可靠导致的错觉。

如果你的业务逻辑确实不需要固定顺序（比如只需要分区内任意一行的历史值），这种场景非常罕见，而且完全不推荐，因为结果稳定度为零。

2. LAG函数可以不带OVER子句吗？ #

标准SQL中绝对不允许，窗口函数（包括LAG、LEAD、ROW_NUMBER等）必须搭配OVER子句来定义窗口范围。部分数据库的非标准旧版本可能允许省略OVER，但这属于不合规范的扩展行为，完全不具备可移植性，而且返回的结果是整个表中随机一行的对应值，和你理解的“随机值”一致，这种写法应该彻底避免。

3. 未指定OVER子句或ORDER BY是否应当报错？ #

• 未指定OVER子句：符合标准SQL的主流数据库（比如PostgreSQL、SQL Server、MySQL 8+）都会直接报错，因为窗口函数必须依赖OVER定义窗口。只有极少数非标准数据库可能不报错，但这是不符合规范的实现。
• OVER子句中未指定ORDER BY：标准SQL允许这种写法，但属于“不安全”用法——数据库通常不会报错，但部分数据库会给出警告（需开启警告日志才可见），因为此时窗口内的行顺序是未定义的，结果不可靠。

总结建议 #

• 永远为LAG函数的OVER子句指定明确的ORDER BY，这是保证窗口函数结果确定性的核心要求，避免依赖数据库的隐式顺序。
• 严格遵守标准SQL规范，不要省略OVER子句，避免在不同数据库间迁移时出现兼容性问题。
• 当窗口函数结果异常时，优先检查PARTITION BY和ORDER BY的定义是否符合业务逻辑，尤其是过滤条件变化对执行计划的影响。

内容的提问来源于stack exchange，提问作者bpeikes