本文介绍如何在 MySQL 8.0+ 中仅用一条 SQL 查询，精准定位指定房间中「当前庄家（dealer=1）的下一位玩家」；若庄家已是最后一条记录，则自动返回该房间的第一位玩家。核心依赖 LEAD() 和 FIRST_VALUE() 窗口函数配合条件逻辑。
本文介绍如何在 mysql 8.0+ 中仅用一条 sql 查询，精准定位指定房间中「当前庄家（dealer=1）的下一位玩家」；若庄家已是最后一条记录，则自动返回该房间的第一位玩家。核心依赖 `lead()` 和 `first_value()` 窗口函数配合条件逻辑。
在多人在线游戏、牌局轮庄等业务场景中，常需动态确定“当前庄家之后的下一位玩家”。例如：当 player_id = 4 是房间 room_id = 1 的庄家时，应返回 player_id = 5；而当 player_id = 5 成为庄家时，因它是该房间最后一名玩家，系统应自动“循环”取第一位玩家（即 player_id = 1）。这一需求看似简单，但用传统子查询或自连接难以优雅实现——尤其要求单条 SQL、无应用层逻辑、支持多房间并发处理。
MySQL 8.0 引入的窗口函数为此类问题提供了简洁可靠的解决方案。关键在于组合使用以下三个函数：
- LEAD(player_id) OVER (PARTITION BY room_id ORDER BY id)：获取同房间内按 id 排序的下一行 player_id；
- FIRST_VALUE(player_id) OVER (PARTITION BY room_id ORDER BY id)：获取该房间第一条记录的 player_id（即首位玩家）；
- FIRST_VALUE(player_id) OVER (PARTITION BY room_id ORDER BY id DESC)：获取该房间最后一条记录的 player_id（用于判断是否为末尾庄家）。
通过 CASE 表达式统一调度逻辑：
- 若当前行 dealer = 1 且其 player_id 等于该房间末尾玩家 → 返回首位玩家；
- 若当前行 dealer = 1 但非末尾 → 返回 LEAD() 结果；
- 其他行不参与输出（后续可过滤）。
以下是完整、可直接运行的解决方案（含 CTE 封装，便于复用与维护）：
WITH dealer_next AS (
SELECT
*,
CASE
-- 庄家是房间最后一人 → 返回首位玩家
WHEN dealer = 1
AND player_id = FIRST_VALUE(player_id) OVER (
PARTITION BY room_id ORDER BY id DESC
)
THEN FIRST_VALUE(player_id) OVER (
PARTITION BY room_id ORDER BY id
)
-- 庄家不是最后一人 → 返回下一位玩家
WHEN dealer = 1
THEN LEAD(player_id) OVER (
PARTITION BY room_id ORDER BY id
)
END AS next_player_id
FROM room_players
)
SELECT room_id, next_player_id
FROM dealer_next
WHERE next_player_id IS NOT NULL;✅ 执行效果示例（基于原始数据 + 扩展测试）：
+---------+----------------+ | room_id | next_player_id | +---------+----------------+ | 1 | 7 | | 2 | 15 | +---------+----------------+
其中房间 1 的庄家是 player_id = 4（id = 4），下一位为 7；房间 2 的庄家是 77（id = 9），下一位为 15（id = 10），符合预期。
⚠️ 注意事项与最佳实践：
- 版本要求：必须使用 MySQL 8.0 或更高版本（窗口函数不可降级兼容）；
- 排序依据：本方案以 id 字段作为逻辑顺序基准，确保 ORDER BY id 能真实反映玩家入座/行动顺序；若业务中顺序由其他字段（如 created_at）决定，请同步替换 ORDER BY 子句；
- 性能优化：为 room_id 和 id 建立联合索引（如 INDEX idx_room_id_id (room_id, id)）可显著提升窗口函数计算效率；
- 空值处理：LEAD() 在末尾返回 NULL，FIRST_VALUE() 在空分区返回 NULL，因此 WHERE next_player_id IS NOT NULL 是安全过滤的关键；
- 可维护性权衡：虽然单查询“优雅”，但复杂窗口逻辑可能增加 DBA 理解成本；对于高变更频率的业务，也可考虑封装为视图或存储过程，兼顾清晰性与复用性。
该方案不仅满足原始需求，更具备良好的扩展性——轻松支持多房间并行计算、动态庄家切换、以及未来加入踢出/重连等状态字段的平滑演进。
