高效更新聚合表PlayDaySeq：插入新记录后重排序列并清理超量数据

针对你这种2.5亿条的超大表场景，全表重新计算ROW_NUMBER绝对是下下策——我们要做的是只处理受增量数据影响的用户，把操作范围压缩到最小，这样才能保证效率。核心思路是：只有那些新增了记录的用户，他们的序列才需要调整，其他用户完全不用碰。

具体实现步骤 #

1. 先锁定需要处理的用户

把增量表#Inc里的用户ID提取出来存到临时表，避免后续多次扫描#Inc：

CREATE TABLE #AffectedUsers (UserId int PRIMARY KEY);
INSERT INTO #AffectedUsers SELECT DISTINCT UserId FROM #Inc;

给临时表加主键约束，能让后续的JOIN操作更快。

2. 调整已有记录的序列值

对这些用户的旧记录，把他们的PlayDaySeq统一加1——这样原来的序列1会变成2，原来的9变成10，原来的10变成11（后续会被删除）：

UPDATE M
SET PlayDaySeq = M.PlayDaySeq + 1
FROM #Main M
JOIN #AffectedUsers AU ON M.UserId = AU.UserId
WHERE M.PlayDaySeq <= 9; -- 可选：提前过滤掉即将被删除的原10号记录，减少更新量

3. 确保新增记录的序列为1

虽然你插入时可能已经把PlayDaySeq设为1，但为了保险（比如插入逻辑有偏差），再更新一次：

UPDATE M
SET PlayDaySeq = 1
FROM #Main M
JOIN #Inc I ON M.UserId = I.UserId AND M.DateId = I.DateId;

4. 删除超量记录

把这些用户中PlayDaySeq大于10的记录删掉（也就是原来的第10条记录，加1后变成11）：

DELETE M
FROM #Main M
JOIN #AffectedUsers AU ON M.UserId = AU.UserId
WHERE M.PlayDaySeq > 10;

为什么这个方案高效？ #

• 最小化操作范围：只处理有新增记录的用户，而不是扫描全表2.5亿条数据，IO和锁的压力骤减。
• 利用索引加速：只要#Main表有UserId的主键或非聚集索引，所有JOIN和WHERE操作都能快速定位到目标记录，避免全表扫描。
• 避免全表排序：全表计算ROW_NUMBER需要对整个表做分区排序，这对超大表来说是灾难性的，而我们的方案完全不需要这个操作。

关键注意事项 #

• 确保#Main表有(UserId)的索引，最好是(UserId, PlayDaySeq)的复合索引，能进一步加速更新和删除操作。
• 如果你的增量数据是批量插入（一次多个用户），这个方案完全兼容，#AffectedUsers会自动覆盖所有需要处理的用户。
• 建议把这些操作放在一个事务里执行，避免中间状态出现数据不一致，但因为操作范围小，事务的锁持有时间会很短。

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