1. 考场动线拆解：先弄清分区、排序与编号
每到考试季，教务那边最头疼的事往往不是出题，而是排考场。某高校期末考试基本是上万人规模，几十个科目、多个考点交叉在一起，既要保证同科目考生分批进入对应教室，又要按考号把座位排得规整，还经常附带一些“同班学生尽量散开”“某些学院单独占楼”之类的要求。这类需求落到数据库层面，最顺手的工具就是 SQL Server 的窗口函数 PARTITION BY。
PARTITION BY 和普通 GROUP BY 看着像，实际是完全不同的逻辑。GROUP BY 是做聚合，一个分组最终只保留一条汇总行；PARTITION BY 是在不丢失原始行的前提下，给每一行附加“组内序号”。排考场这件事本质上就是“对每一组考生分别编号”，所以PARTITION BY 几乎是标准答案：先按科目或考点把考生切成若干组，再在组内按考号排顺序，最后把序号翻译成“第几考场 + 几号座位”。
动手写 SQL 之前，我建议先把数据模型理清楚。以某高校实际场景为例，通常有两张核心表：一张是考生基础信息表，字段大概有 StudentID（考号）、StudentName（姓名）、CollegeCode（学院代码）、ClassName（班级）；另一张是考试报名表，记录每个考生在某场考试中归属的考点、科目、考试时间。输出结果则需要一张“考场编排明细表”，每行包含考生ID、科目、考点、考场号、座位号。只要这几张表结构固定，后续所有复杂编排都只是在这套骨架上加规则。
很多刚接触窗口函数的人会踩一个误区：以为 PARTITION BY 只能按一个字段分组。其实它可以多字段组合，比如同时按“科目 + 考点”分区，这样同一个考点下每个科目都从 1 号开始重新计算，这正是考场编排需要的效果。先想明白要输出什么，再去写分区和排序，后面代码通常一遍就能跑通。
2. 函数选型：PARTITION BY 与四类序号函数怎么搭配
PARTITION BY 只是窗口函数语法中的分区部分，真正做编号的是跟在后面的 ROW_NUMBER()、RANK()、DENSE_RANK() 或 NTILE()。很多新手以为四个函数差不多，实际用起来差别很大。我直接用考场场景来解释。
ROW_NUMBER() 是最常用的，它给组内每一行分配一个连续且不重复的整数，1、2、3、4……依次递增。排考场时，这个序号可以直接映射成“全考场的第几个入座”，再通过数学计算拆出考场号和座位号。RANK() 和 DENSE_RANK() 会处理并列值：如果排序字段相同，两者都会给出相同名次，区别在于 RANK() 后续会跳过名次（比如两个并列第1，下一位就是第3），DENSE_RANK() 则连续编号（下一位是第2）。排考场时我们通常不希望出现“并列座位号”，因为一个座位只能坐一个人，所以默认行号就用 ROW_NUMBER()。
那 RANK 和 DENSE_RANK 是不是完全没用？也不是。有一种常见需求是“每个考场选第一排考生作为临时联络员”，如果排序依据是考生的综合成绩、且允许成绩并列时多选一人，就要用 RANK；如果必须严格选固定人数，那么 RANK 就不再适合，需要用 ROW_NUMBER 强行截断。NTILE(n) 则会把分组数据尽量均匀地切成 n 份，考场编排里比较少见，但如果要把一个考点的考生近似均分到 N 个教室，它倒是个取巧的办法。
选完函数后，真正影响输出质量的是 ORDER BY 字段。排考场默认会按考号排，这没问题。但如果考号是字符串类型，就很容易掉进“字典序”的坑，比如“1002”排在“99”前面。解决办法有两个方向：一是把考号字段设计成定长数字字符串，让字典序和数值序完全一致；二是在 ORDER BY 中显式转换，比如 ORDER BY CAST(StudentID AS INT)。我通常更建议前者，数据库设计阶段就把考号规范成统一长度，后面所有编号逻辑都省心。
另外要提醒一点：窗口函数中 ORDER BY 后面的字段不一定非得是业务主键，也可以写多个字段。比如某些学校要求“同一考点的考生先按性别分开、再按考号排序”，SQL 写法就是在 ORDER BY 后加 Gender, StudentID。分区和排序字段选对了，整个编排脚本就成功了一半。
3. SQL实操：一套可复用的考场编排脚本
下面这套脚本是我在模拟项目X里反复用过的结构，适合大多数“按考点 + 科目分区、按考号排序、标准考场容量”的编排需求。先上一段核心 SQL。
SELECT reg.StudentID, stu.StudentName, reg.Subject, reg.CampusID, ROW_NUMBER() OVER ( PARTITION BY reg.Subject, reg.CampusID ORDER BY stu.StudentID ) AS Seq, (ROW_NUMBER() OVER ( PARTITION BY reg.Subject, reg.CampusID ORDER BY stu.StudentID ) - 1) / 30 + 1 AS RoomNo, (ROW_NUMBER() OVER ( PARTITION BY reg.Subject, reg.CampusID ORDER BY stu.StudentID ) - 1) % 30 + 1 AS SeatNo FROM ExamRegistration reg INNER JOIN StudentInfo stu ON stu.StudentID = reg.StudentID ORDER BY reg.Subject, reg.CampusID, RoomNo, SeatNo;这段代码输出四列关键信息：组内连续序号 Seq、考场号 RoomNo、座位号 SeatNo，以及考生基本资料。假设一个标准考场容量为30人，那么第1到第30号考生在 RoomNo=1，第31到第60号在 RoomNo=2，以此类推。这里用到的数学技巧是“减1再整除”：序号1减1得0，除以30取整得0，再加1就是考场号1；序号30减1得29，除以30取整得0，考场号仍是1；序号31减1得30，除以30取整得1，考场号变成2。座位号则用取模运算，序号1减1取模30得0再加1，座位号是1；序号30减1取模30得29再加1，座位号是30。这个计算是整个编排逻辑的核心，建议封装成视图或存储过程后续复用。
既然出现了两段几乎一样的 ROW_NUMBER() OVER 子句，也可以先用子查询生成序号，再在外层计算考场号和座位号，代码会更清爽。
WITH SeatSeq AS ( SELECT reg.StudentID, stu.StudentName, reg.Subject, reg.CampusID, ROW_NUMBER() OVER ( PARTITION BY reg.Subject, reg.CampusID ORDER BY stu.StudentID ) AS Seq FROM ExamRegistration reg INNER JOIN StudentInfo stu ON stu.StudentID = reg.StudentID ) SELECT StudentID, StudentName, Subject, CampusID, (Seq - 1) / 30 + 1 AS RoomNo, (Seq - 1) % 30 + 1 AS SeatNo FROM SeatSeq ORDER BY Subject, CampusID, RoomNo, SeatNo;实测下来，这套写法比直接算要好维护得多。后续如果需要调整考场容量，只需改动一次“30”，不用去翻重复的窗口函数。更重要的是，把 PARTITION BY 写到 CTE 里之后，如果你想基于“组内序号”做进一步筛选，比如抽出每个考场前5名应急人员，可以直接 WHERE Seq <= 5，非常方便。
这段脚本还有一个容易被忽略的特性：INNER JOIN 会自然过滤掉没有报名记录的考生，这正好符合“只编排已缴费/已确认的考生”的业务规则。如果某个考生信息缺失导致 JOIN 不上，外连接会把 NULL 也带进结果集，这几个 NULL 会被 PARTITION BY 归到一组，很可能单独形成一个考场号，这就是后面要讲的坑之一。
4. 复杂场景扩展：随机混排、按学院拆分与容量差异
基础版本能解决大部分普通考试，但实际业务中经常有额外限制。我在历次排考过程中总结了几类高频变体，每一类都可以在原有 SQL 上做小改动实现。
第一种是随机编排。有些考试希望考生座位尽量随机，避免同校或同班考生扎堆。做法很简单，把窗口函数中的 ORDER BY stu.StudentID 换成 ORDER BY NEWID()。NEWID() 是 SQL Server 生成 GUID 的函数，每次执行都能产生新的随机顺序，ROW_NUMBER 基于这个随机顺序编号，座位自然就随机了。注意一点：随机编排后输出结果的总体顺序也不要按座位号排得过于规律，否则考生进场时容易发现规律，实际使用时我倾向于按“考场号 + 考号”输出，真实座位号只用于贴桌贴。
第二种是“同班错开”。编辑时希望同一个班的考生不要集中在同一考场，尤其某些毕业班考试。实现思路是给班级先算一个随机盐值，再把这个值作为排序第一关键字。比如先更新一个临时列 ClassSalt = ABS(CHECKSUM(NEWID()))，然后窗口函数的 ORDER BY 改为 ClassSalt, StudentID。这样同一个班级的 ClassSalt 相同，班内考生考号连续，但不同班级的盐值随机，整体混合后同班考生会被拆散到不同考场。这个方案的缺点是每执行一次都会重新混排，如果教务需要固定编排结果，就必须把生成的 ClassSalt 持久化保存。
第三种是每个考场容量不一致的情况。现实中不同教室能坐的人数不一样，有些能坐30，有些只能坐24。用固定整除的方式就行不通了。推荐做法是维护一张“考点-考场容量表”，包含 CampusID、RoomID、Capacity 和每个考场的起始序号 StartSeq。然后通过累计求和的方式，算出每个考生的序号应该落在哪个考场区间。
WITH CapacityCumulative AS ( SELECT CampusID, RoomID, Capacity, SUM(Capacity) OVER (PARTITION BY CampusID ORDER BY RoomID) AS CumulativeCap FROM CampusRoom ), SeatSeq AS ( SELECT reg.StudentID, reg.CampusID, ROW_NUMBER() OVER ( PARTITION BY reg.Subject, reg.CampusID ORDER BY reg.StudentID ) AS Seq FROM ExamRegistration reg ) SELECT s.StudentID, s.CampusID, c.RoomID, s.Seq - ISNULL(LAG(c.CumulativeCap) OVER (PARTITION BY s.CampusID ORDER BY c.RoomID), 0) AS SeatNo FROM SeatSeq s LEFT JOIN CapacityCumulative c ON s.CampusID = c.CampusID AND s.Seq > LAG(c.CumulativeCap) OVER (PARTITION BY c.CampusID ORDER BY c.RoomID)这个写法看起来有点绕，核心思路是：先用累计容量算出每个考场的“编号区间”，再让考生的组内序号落到某个区间里，最后用“当前序号减去上一考场的累计容量”得到考场内座位号。实际项目中我更常用另一种方式：直接用 WHILE 循环逐考场分配考生，逻辑清晰、排查方便，只是在大数据量下性能稍差。如果数据量在十万行以内，循环方案完全够用。
第四种是按学院或按性别分区。比如某些考点是按学院独立分配楼栋的，这时候只要把 PARTITION BY 改为 PARTITION BY reg.CollegeCode, reg.Subject，考场号就会在每个学院内独立计算。如果希望男女座位分开，就在分区里加入 stu.Gender，但要注意这样会产生更多考场数量，教务一般不太接受，建议结合业务确认。
第五种是“每组前 N 名”的使用。比如考场编排完成后，需要给每个考场选出前两名考生当作备用联络人，用 CTE 版本就可以轻松实现：
WITH SeatSeq AS (...) SELECT * FROM SeatSeq WHERE Seq <= 2;这种做法的好处是不用二次自连接，代码可读性也好。我在之前某个图像处理Demo项目里也用过同样的思路去分批次处理数据，窗口函数确实不止存在于报表统计中。
5. 避坑实录：常见报错、异常结果与排查思路
窗口函数写起来爽，坑也不少。我把这些年被问得最多的几个问题整理成一张速查表，每一条都是实际踩过或协助排查过的。
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 分区后的序号莫名多出N组，出现很多“1号座位” | 分区字段包含 NULL，LEFT JOIN 导致的空值被单独分组 | 排查分区字段是否允许 NULL，必要时用 ISNULL 填充占位值或改用 INNER JOIN |
| 按考号排序时出现 1002 排在 999 之前 | 考号字段是 varchar，按字典序排序 | 设计时用定长字符，或查询时显式转成 INT；实在改不了就加一个排序列 |
| 窗口函数和 DISTINCT 同时使用结果异常 | DISTINCT 在去重之前窗口函数已经计算完毕 | 先对明细表去重生成 CTE，再基于 CTE 计算窗口函数 |
| 同一考生多科目报名，编排表出现重复行 | 报名表存在一条考生多科记录，分区里没区分科目 | 在 PARTITION BY 中加入 Subject；若是同一科目重复报名则先按业务规则去重 |
| 随机排考场每次结果不同，无法留档 | NEWID() 每次执行都变化 | 生成一次结果后物化到正式表，或为每个考生生成随机种子列并保存 |
| 大考点（几千人）执行特别慢 | PARTITION BY + ORDER BY 字段没有索引 | 为分区字段和排序字段建立组合索引，例如 (Subject, CampusID, StudentID) |
这里重点说前两个。NULL 分组问题，我碰到过一次真实的案例：某系统把“考试批次号”作为分区字段，实际有部分老数据批次号为空，结果所有这些考生被单列成一个考场组，输出的 RoomNo 直接从几千号开始跳。排查时看结果表里怎么找都找不到对应考场，后来一查是 NULL 值在作怪。所以分区字段最好都定义成 NOT NULL，如果历史数据已经脏了，就在分区前加 COALESCE 把空值归入默认组。
字符串排序问题更隐蔽。很多高校的考号是类似“20230001”这种八位字符串，它前四位是年份，从“20230001”到“20231000”字典序和数值序恰好一致，所以一直没暴露问题。一旦出现“202399”这种连号缩短的老考号，排序瞬间乱套。建议在表设计时就增加一个 BIGINT 类型的 StudentNoSeq 排序列，由程序写入，查询时直接 ORDER BY StudentNoSeq，一劳永逸。
还有一块容易出错的逻辑是考生“一人多科”。排考场按科目分区时，同一个考生在上午考语文、下午考数学，会在不同分区中各出现一次，这本身是合理的。但教务打印桌贴时如果只按姓名搜索，就会看到同一个名字出现在多个考场，容易被误判为重复数据。处理方式是输出时把科目信息完整带上，并在文档抬头注明“本名单按科目独立编排”。
最后说一个关于索引的实操心得。PARTITION BY 场景中最影响性能的算子其实是排序。如果表数据量在百万级，建议在 (Subject, CampusID, StudentID) 上建一个组合索引，让窗口函数直接从索引读取有序数据，减少排序开销。实测下来在一个 80 万行报名表上，加索引前后耗时从 12 秒降到 3 秒以内，效果非常明显。如果库还在不断写入，索引数量不宜过多，一般两个组合索引足够覆盖考场编排和后续查询了。
我在实际编排考场时还有个习惯：所有规则跑通后，先跑一小批数据（比如只选一个科目）导出 Excel 人工检查一遍，确认教室编号、座位号没有跳号或重复，再全量执行。窗口函数的结果从逻辑上通常没问题，但业务数据经常会有脏数据，提前用抽样脚本查一遍能省掉很多事后返工的时间。这套 PARTITION BY 编排考场的方法，后续要扩展也是现成的思路——换掉分区维度就是按学院，换掉排序字段就是随机，换掉容量表就是多教室联动，唯一不变的核心就是“分区 + 排序 + 映射”。
