LAG()函数配合ORDER BY可验证组内字段是否严格递增，需处理NULL、重复值及排序稳定性，聚合时用MIN()或BOOL_AND()判断全组是否满足，边界情况须按业务明确定义。
用LAG()比较组内前一行值是否严格小于当前行
直接判断分组后某字段是否单调递增，本质是验证每组内相邻记录的值是否满足 current_value > previous_value。MySQL 8.0+、PostgreSQL、SQL Server 等支持窗口函数的数据库，首选 LAG() 函数获取上一行值，再做布尔判断。
-
LAG()必须配合ORDER BY使用，否则“上一行”无定义；顺序错会导致误判 - 首次出现的记录（组内第一行）
LAG()返回NULL，需用IS NULL单独处理，不能直接参与>比较 - 若允许相等（即非严格递增），应改用
>=，但注意业务语义：时间戳字段通常要求严格递增，ID字段可能允许重复插入后重排
示例：检查每个 user_id 组内 score 是否严格递增
SELECT user_id,
score,
LAG(score) OVER (PARTITION BY user_id ORDER BY created_at) AS prev_score,
score > LAG(score) OVER (PARTITION BY user_id ORDER BY created_at) AS is_increasing
FROM attempts;
聚合判断整组是否全部满足递增条件
单看每行布尔结果还不够——你往往需要知道“该用户所有记录是否全程递增”。这时要用 MIN() 或 BOOL_AND()（PostgreSQL）对组内所有 is_increasing 值做聚合。
- MySQL 8.0+ 可用
MIN(is_increasing)，因为布尔值在 MySQL 中转为0/1，MIN()为 0 表示存在至少一处不满足 - PostgreSQL 推荐
BOOL_AND(is_increasing)，语义更清晰 - 注意：若组内仅一条记录，
LAG()为NULL，对应行的is_increasing为NULL，MIN()会忽略NULL，结果为 1 —— 这符合逻辑（单点默认视为“未违反递增”）
完整写法（MySQL）：
SELECT user_id,
MIN(score > LAG(score) OVER (PARTITION BY user_id ORDER BY created_at)) AS full_increasing
FROM attempts
GROUP BY user_id;
避免因NULL或重复值导致误判
实际数据中，score 字段本身可能为 NULL，或存在相同值。这两类情况会让 > 判断直接返回 NULL，进而影响聚合结果。
- 先过滤掉
score IS NULL的行，或用COALESCE(score, -999999)填充（需确保填充值低于所有合法值） - 若业务允许相等，用
>=替代>；但若字段本应唯一（如自增ID），出现相等就代表异常，此时应保留>并查出具体冲突位置 - 当
ORDER BY字段（如created_at）存在重复，必须加入第二排序键（如id）打破并列，否则LAG()行为不可预测
替代方案：用自连接或变量模拟LAG（兼容旧版MySQL）
MySQL 5.7 或更早版本不支持窗口函数，只能靠自连接或用户变量。但变量方式在并发或优化器重排时不稳定，强烈建议升级到 8.0+。
- 自连接写法性能差，尤其大数据量分组：需对每组做
JOIN找前一行，复杂度接近 O(n²) - 用户变量（如
@prev := ...）依赖执行顺序，在ORDER BY和WHERE交互时极易出错，MySQL 官方已明确不保证其可靠性 - 如果真无法升级，优先考虑应用层校验：拉取每组有序数据，在代码里遍历比对，可控性远高于 SQL 层模拟
真正难的不是写出判断语句，而是确认“递增”的业务定义是否覆盖了边界情况：单记录、NULL、重复时间戳、多字段联合排序……这些地方一漏，检测就形同虚设。
