在 SQL 中，使用窗口函数 ROW_NUMBER() 结合 PARTITION BY user_id 和 ORDER BY login_time ASC 可以高效地按用户分组，并在每个组内按登录时间进行排序。不过有一个常见细节容易出错：如果忘记添加 PARTITION BY，数据库会生成全局顺序编号，导致所有用户的登录记录混在一起排序，无法得到期望的分组排序结果。此外，必须使用 ROW_NUMBER() 来确保编号严格连续——其他排名函数（如 RANK 和 DENSE_RANK）会产生跳号或重复，不适合此场景，后续会详细说明。
窗口函数如何按设备分组排序登录记录？
核心方法很简单：使用 ROW_NUMBER() 函数，配合 PARTITION BY user_id 进行用户分组，再通过 ORDER BY login_time ASC 按登录时间升序排序。注意，数据库的执行逻辑是先按用户分组，然后在每个组内分别排序编号——而不是先对所有记录排序再分组，这一点容易混淆。如果顺序搞反，所有用户的登录时间将被混在一起编号，导致结果无效。
常见错误写法：仅使用 ORDER BY login_time 而忘记添加 PARTITION BY user_id，此时生成的序号是全局的，无法反映每个用户在其设备上的登录顺序。
PARTITION BY user_id：确保每个用户独立编号，互不干扰ORDER BY login_time ASC：按登录时间升序排列，最早的登录记录编号为1- 如果同一秒内存在多条记录，建议添加二级排序字段，例如
ORDER BY login_time, device_id，以避免数据库因不确定顺序而分配不稳定的编号
如何区分同一设备多次登录与首次登录？
仅使用 ROW_NUMBER() 只能获取登录顺序，无法直接标记出“该用户在该设备上的首次登录”。此时需要嵌套查询，结合 MIN() 窗口函数或布尔判断来实现。
典型实现方法是：先计算每个 (user_id, device_type) 组合的最早登录时间，然后与当前记录进行比对：
- 在子查询或 CTE 中，使用
MIN(login_time) OVER (PARTITION BY user_id, device_type)获取每个组合的最早登录时间 - 在外层，利用
CASE WHEN login_time = min_time THEN 1 ELSE 0 END AS is_first_on_device来标记该记录是否为该设备上的首次登录 - 注意：
device_type字段需要进行归一化处理，例如将 'iPhone' 和 'ios' 统一为同一值，否则相同设备类型会因名称不一致而被拆分为多个组，导致统计结果不准确
为何不推荐使用 RANK() 或 DENSE_RANK()？
这三种排名函数的行为有显著区别：ROW_NUMBER() 生成严格递增且无重复的序号；RANK() 在遇到相同登录时间时会产生跳号；DENSE_RANK() 不会跳号但允许重复序号。由于登录顺序需要唯一且连续，只有 ROW_NUMBER() 符合要求。
举个例子，两条登录时间完全相同的记录：
ROW_NUMBER()→ 分别分配 1 和 2（依赖于隐式排序，结果可能不稳定）RANK()→ 都分配 1，下一条记录直接变为 3DENSE_RANK()→ 都分配 1，下一条记录为 2
因此，除非你确实需要“并列第一”的效果，否则应始终使用 ROW_NUMBER()，并确保 ORDER BY 子句中包含足够区分度的字段，例如设备 ID 或精确到毫秒的时间戳，以避免编号不确定性。
MySQL 8.0 以下版本无法使用窗口函数，如何解决？
在 MySQL 8.0 之前的版本中，只能通过用户变量来模拟窗口函数功能，但这种方法极易出错——尤其是当数据没有严格按照 user_id, login_time 排序时，变量自增逻辑会混乱，导致结果不可靠。
实操建议：
- 强制排序：必须确保
ORDER BY user_id, login_time出现在变量赋值的最外层查询中，以保证数据顺序正确 - 变量初始化：将变量初始化放在子查询中，例如
(SELECT @rn := 0) AS init，以避免外部查询的影响 - 更稳妥的方案：直接升级到 MySQL 8.0+，或者改用应用层处理——例如从数据库导出所有记录后，使用 Python 的
itertools.groupby进行分组排序
窗口函数并非简单的语法糖，而是语义清晰、执行稳定的集合操作。使用变量模拟虽然看似可行，但在并发查询或大表分页场景下，容易出现顺序遗漏或编号重复的问题——这些问题往往被忽视，直到线上数据不一致时才被发现。从实际生产环境来看，直接升级数据库版本或改用应用层处理，远比在变量模拟上不断修补要可靠得多。
