期中考试前一周，教务处把一份1200人的考生名单塞过来：40个考场、每场30人，要求同班学生尽量打散，最后还要打印每考场的座次表和门贴。前两年我用Excel处理，又是筛选又是随机数，运气不好还要手动搬人。今年我直接在 MS SQL Server 里用 partition by 窗口函数把整套逻辑写成一条SQL，吃完午饭就把名单交了回去。
这是窗口函数实战系列的第二篇。上一篇聊过成绩排名里 ROW_NUMBER、RANK、DENSE_RANK 那点事，这次把战场拉到排考现场：怎么用 PARTITION BY 把考生按班级、按教研组做“发牌式”分配，生成考场号、座位号，顺带把监考教师也一起编排了。如果你是学校信息中心、教务员或者做考试系统的开发，这篇文章可以直接抄作业。
1. 排考场景的“硬约束清单”：先看清数据，再谈函数
1.1 手里只有两张表，就够跑通全部逻辑
实际排考需求没有想象中复杂。大部分学校教务系统里都有两张基础表：一张考生表，一张教师表。教学班、行政班、年级组这些复杂关系，在排考这个场景里其实都能简化成班级编号。我这里用最精简的表结构演示：
CREATE TABLE dbo.students ( student_id INT PRIMARY KEY, student_name NVARCHAR(50), class_id VARCHAR(20), grade VARCHAR(20) ); CREATE TABLE dbo.teachers ( teacher_id INT PRIMARY KEY, teacher_name NVARCHAR(50), subject NVARCHAR(20), class_id VARCHAR(20) );学生表里一行一名考生，teacher表里一名老师对应自己任教的班级或班主任班级。字段不多，但已经能跑通全部逻辑。我本地测试时先生成了一份40个班、每班30人、合计1200人的模拟数据，规则和今年期中完全一样，后来实际执行结果也很稳定。这篇文章里的SQL大家拿去以后，把自己库里的真实字段名替换掉就行，SQL Server 2016以上版本都支持，不需要额外装任何组件。
1.2 排考规则清单，先列全再动手
一次普通期末联考，教务处通常给这么几条硬约束：
- 标准考场30人/场，尾考场可以不满；
- 同班学生尽量分散到不同考场，最理想情况是“同班同考场人数为0”；
- 每个考场内部按考号排座位，座位号从1到考场实际人数；
- 每考场配2名监考教师，主监和副监不是同一人；
- 班主任最好不监考自己班级，这条在分配完以后做人工收尾；
- 生成的名单必须是固定结果，不能每次刷新都变。
第2条看起来简单，但实现的时候有方向分歧，对应着四种方案，我放到第3章专门对比。第6条经常被人忽略，但它是真正的“硬需求”——窗口函数里一旦出现随机数，每次执行结果就可能不同。名单如果每次刷新都变，别说班主任不答应，你自己复核都过不去。
1.3 为什么 GROUP BY 在这里不够用
很多同事一听说按班级分组，第一反应就是 GROUP BY。GROUP BY 确实能把学生按班级聚起来，但它把行浓缩成组了：比如 SELECT class_id, COUNT(*) FROM students GROUP BY class_id，最后每个班只剩一行汇总数字，1200个考生的明细行全丢光。
而 PARTITION BY 是“分组但不折叠”：它在每一行后面保留所属组的信息，同时给这一行算出一个组内编号，考生的明细行原样保留。排考最需要的恰恰是“每个考生单独一行，但又能知道自己在全班排第几”，所以这里必须用窗口函数而不是 GROUP BY。
我习惯把这两者区别比喻成“点人数”和“发号码牌”。点人数只关心每个小组一共多少人；发号码牌是每个人都拿到自己的号和组信息，但大家还坐在原来的座位上。后面所有排考SQL都围绕这个区别展开。
2. 考生进考场的核心SQL：错峰发牌与二次编号
2.1 先用考生总数算出考场数量
写排考SQL第一步不是开窗口，而是算出考场总数。考场数量由两个变量决定：考生总数和标准考场容量。
DECLARE @roomSize INT = 30; -- 标准考场容量 DECLARE @roomCount INT; SET @roomCount = ( SELECT CEILING(CAST(COUNT(*) AS FLOAT) / @roomSize) FROM dbo.students ); SELECT @roomCount AS room_count;1200人除以30正好是40。如果考生总数是1201，这个写法会算出41，虽然尾考场可能只有1人。实际教务经常把尾考场合并，这个我在第5章专门说。这里先把基础公式摆出来，后面所有取模运算都要用到 @roomCount。
2.2 给每个班安排一个随机“错峰偏移量”
这是整个方案里最关键的一步，也是最容易被忽略的一步。
先看一个错误直觉：很多初学者会把“每个班的第几个学生”直接对考场数取模，比如 (班内序号 - 1) % 40 + 1。问题是，一个班只有30人，考场却有40个，取模结果只会覆盖1到30号考场，后面第31到40考场永远收不到这个班的学生。等40个班都按同样逻辑分配，前30个考场挤满了40个班的学生，后10个考场却一个人都没有。
解决办法是给每个班一个随机起点，让不同的班从不同的考场开始“发牌”。这个起点我称为“错峰偏移量”。
;WITH ClassOffset AS ( SELECT class_id, (ROW_NUMBER() OVER (ORDER BY NEWID()) - 1) % @roomCount AS offset_no FROM ( SELECT DISTINCT class_id FROM dbo.students ) d ) SELECT * FROM ClassOffset;这里先用 DISTINCT 取出所有班级，再按 NEWID() 随机排列班级，最后用 ROW_NUMBER 生成从1开始的序号。减1以后对40取模，得到0到39之间的一个随机起点。班级数如果超过40，取模后允许有重复偏移，不影响使用。
2.3 班内序号加偏移量，算出每个考生的考场号
有了班级偏移量，再把每个考生在班级内的序号算出来，两者相加就得到考场号。
;WITH ClassOffset AS ( SELECT class_id, (ROW_NUMBER() OVER (ORDER BY NEWID()) - 1) % @roomCount AS offset_no FROM ( SELECT DISTINCT class_id FROM dbo.students ) d ), StudentSeq AS ( SELECT s.student_id, s.student_name, s.class_id, ROW_NUMBER() OVER ( PARTITION BY s.class_id ORDER BY s.student_id ) AS seq_in_class FROM dbo.students s ) SELECT ss.student_id, ss.student_name, ss.class_id, (co.offset_no + ss.seq_in_class - 1) % @roomCount + 1 AS room_no FROM StudentSeq ss INNER JOIN ClassOffset co ON ss.class_id = co.class_id ORDER BY room_no, class_id, student_id;PARTITION BY s.class_id 在这里做的事，就是让每个班独立编号：第1个学生 seq_in_class=1，第30个学生 seq_in_class=30。因为每个班只有30人，这个班只覆盖30个考场，至于覆盖哪30个考场，完全由班级偏移量决定。
举例：A班偏移量是5，那么第1个学生去(5+1-1)%40+1=6号考场，第2个学生去7号考场，第30个学生去35号考场。B班偏移量如果是20，就覆盖21到50号考场，但模运算会在41号考场时折回1号考场。40个班各自偏移，互相错开，才能让每个考场的总人数都接近30。
这个方案还附带一个巨大优点：同一个考场里，同一个班最多只可能出现1个人。因为每个考生的 seq_in_class 是唯一值，一个 seq_in_class 只对应一个考场号，班级里30个人分别落在30个不同考场。同班分离这个约束被直接写进了算法，不需要事后检查。
2.4 考场内二次编号：座位号与考号一次生成
考场号确定了，接下来要给每个考场内部的考生排座位。这一步同样用 PARTITION BY，只是分区键从班级换成考场号。
;WITH ClassOffset AS (...), StudentSeq AS (...), Room AS ( SELECT ss.student_id, ss.student_name, ss.class_id, (co.offset_no + ss.seq_in_class - 1) % @roomCount + 1 AS room_no FROM StudentSeq ss INNER JOIN ClassOffset co ON ss.class_id = co.class_id ) SELECT room_no, ROW_NUMBER() OVER ( PARTITION BY room_no ORDER BY class_id, student_id ) AS seat_no, student_id, student_name, class_id, room_no * 100 + ROW_NUMBER() OVER (PARTITION BY room_no ORDER BY class_id, student_id) AS exam_no FROM Room ORDER BY room_no, seat_no;考场内统一按班级和学号排序，出来的座位号是稳定的。考号直接用“考场号×100+座位号”拼接，比如6号考场第5个座位，考号就是605。这个规则在40个考场、每场30人的规模下绝对够用，不会重复。
如果不想在同一层 SELECT 里写两边 ROW_NUMBER，也可以用子查询先算出 seat_no，再算 exam_no，效果一样，看你习惯。我实际更喜欢子查询的写法，不容易漏同步修改。
3. 均匀与隔离的取舍：四种分配方案实测对比
3.1 方案A：NTILE 整体随机，人数最均衡但同班易聚
有人会问：直接用 NTILE 不行吗？NTILE(@roomCount) OVER (ORDER BY NEWID()) 能把1200人尽量等分成40组，每组恰好30人，从人数均匀性上看无懈可击。
SELECT student_id, student_name, class_id, NTILE(@roomCount) OVER (ORDER BY NEWID()) AS room_no FROM dbo.students;问题在于它完全不看班级。同班同学被随机打散到40个考场，看起来也算分散，但实际上同考场相遇概率很高。我们可以粗略算一下：1200人、40个考场，任意两个考生分到同一考场的概率大约是(30-1)/(1200-1)，接近2.4%。一个40人的班级里，任意两人同考场的期望对数大约有 C(40,2)×2.4%，约18.6对。也就是说，一个班40个人和40个考场随机撞，几乎必然出现大量同班撞考场的情况。
这也解释了为什么 NTILE 虽然“平均”，但解决不了“同班隔离”这个真实需求。排考不是分饼，光均匀不隔离，考场上全是熟人，监考压力会陡增。
3.2 方案B：班内编号直接取模，一个隐蔽的大坑
这是初学者最容易写出来的方案：先把每个班的考生按学号编号，然后用 (seq_in_class - 1) % @roomCount + 1 直接当考场号。
我在2.2已经说过它的致命问题：当一个班的人数小于考场数时，这个班只会覆盖最前面的 N 个考场。拿40个班、每班30人、40个考场来说，每个班的考生都只会进1到30号考场，结果就是前30个考场每个装40人，严重超员；31到40号考场一个考生都没有。这已经不只是“不均”的问题，而是直接跑出废名单。
如果考场数刚好不大于班级人数，比如每班40人、只有20个考场，那方案B倒是能用，每个班恰好铺满所有考场。但大多数排考场景都是“班人数小于考场数”，所以这个坑踩中概率极高。我第一年用 SQL 排考就犯过这个错，当时教务老师看了一眼人数统计表，直接问我“后面十个考场怎么空着”。
3.3 方案C：错峰发牌，兼顾均匀与隔离
第2章完整写出的就是方案C。它本质上是方案B的升级：给每个班加一个随机偏移量，让不同班级从不同考场开始发牌。
效果怎么样？我拿1200人、40个考场的测试数据跑了一遍，结果每个考场人数基本在28到33之间波动，没有出现空考场，也没有出现严重超员，同班同考场人数为0。虽然每个考场不保证严格等于30人，但教务场景里28到33人完全可接受，后续少量微调只在极端情况下才需要。
方案C的SQL也不复杂，虽然多了一个 ClassOffset CTE，但逻辑非常直观。如果非要一个严格30人的结果，可以在方案C基础上加一次手动调整，或者直接选用下面的方案D。
3.4 方案D：两阶段加人工微调，真实教务的最终答案
我在实际项目中并不会只跑一句SQL就交付。更稳妥的做法是先跑方案C，把结果固化到临时表，再统计人数分布：
;WITH ClassOffset AS (...), StudentSeq AS (...), Room AS ( SELECT ... -- 方案C完整逻辑 ) SELECT room_no, COUNT(*) AS student_count FROM Room GROUP BY room_no ORDER BY room_no;然后检查每个考场人数。如果某个考场超过33人、某个考场少于27人，优先把“多”的那个考场里按座位号最靠后的考生，挪到“少”的考场。因为方案C里同一个考场不会出现来自同一个班的考生，挪人的时候不会破坏同班隔离的成果。
这个人工微调量通常在一两个考生以内。为了一个学期一次排考去写复杂的游标贪心算法，性价比太低。手工调整后把结果保存下来，整个过程就结束了。
3.5 一张选择表，按情况对号入座
| 方案 | 人数均衡 | 同班隔离 | SQL复杂度 | 适用场景 |
|---|---|---|---|---|
| A NTILE整体随机 | 严格均衡 | 差，同班撞考场概率高 | 低 | 联考、混合随机，不关心班级 |
| B 班内编号直接取模 | 差，班人数小于考场数时严重失衡 | 好 | 低 | 仅适用于考场数不超过班人数 |
| C 错峰发牌 | 接近均衡，28到33之间 | 好，同班同考场为0 | 中 | 本校排考首选 |
| D 错峰发牌加人工微调 | 可做到严格30人 | 好 | 中+人工 | 必须严格满场的正式考试 |
4. 监考教师编排：PARTITION BY的另一个高频场景
4.1 监考排班通常有哪些规则
考场人员不只包含考生，监考教师也要一并编排。教务处给的监考规则一般是：
- 每个考场2名监考，分别叫主监和副监；
- 主监从语文、数学、英语三个教研组里出；
- 副监从其他学科教研组里出；
- 同一个教研组的老师尽量不重复出现在同一个考场；
- 班主任不监自己班，这条通常最后人工核对。
PARTITION BY 在这里的最大价值，是按教研组分组以后给老师做“轮转”编号。每个教研组内的老师独立编号，再对考场数取模，就能保证组内老师均匀铺到所有考场。
4.2 主监考分配：按教研组轮转
我先写主监考的分配逻辑。假设语文、数学、英语三个组各40人，要求每组老师分散到40个考场。
DECLARE @roomCount INT = 40; ;WITH Main AS ( SELECT teacher_id, teacher_name, subject, ROW_NUMBER() OVER ( PARTITION BY subject ORDER BY NEWID() ) AS seq_in_subject FROM dbo.teachers WHERE subject IN (N'语文', N'数学', N'英语') ) SELECT (seq_in_subject - 1) % @roomCount + 1 AS room_no, teacher_id, teacher_name, subject FROM Main ORDER BY room_no, subject;这里 PARTITION BY subject 给语文、数学、英语三个组各自编号，三个组的第1名都进1号考场，第2名都进2号考场。也就是说，一个考场里可能出现语文和数学两个主监，没关系，最终主监只需要一人，下面补位时再处理。
如果某个教研组刚好40人，那么它恰好给每个考场贡献1人。如果只有39人，1到39号考场各有一名该组老师，第40号考场就要靠其他组补位。
4.3 副监考与空考场补位
副监考从物理、化学、生物、政治、历史、地理、音体美等组里抽。写法与主监一致，只是筛选条件不同。为了把主监和副监拼成一张完整表格，我习惯先造一个1到40的数字序列，再左连接两边分配结果：
;WITH Numbers AS ( SELECT TOP (@roomCount) ROW_NUMBER() OVER (ORDER BY (SELECT 1)) AS n FROM sys.all_objects ), Main AS ( SELECT ... -- 主监考分配逻辑，room_no ), Vice AS ( SELECT ... -- 副监考分配逻辑，room_no ) SELECT N.n AS room_no, M.teacher_name AS main_teacher, V.teacher_name AS vice_teacher FROM Numbers N LEFT JOIN Main M ON M.room_no = N.n LEFT JOIN Vice V ON V.room_no = N.n ORDER BY N.n;LEFT JOIN 可以快速暴露空缺：如果某考场 main_teacher 是 NULL，说明主监不足，需要从其他教研组补。放到数字序列上处理，比直接查询结果更直观，也方便后续导出考务表。
4.4 班主任回避本班的收尾检查
班主任不监自己班，这条用窗口函数很难直接写进分配逻辑，因为考场分配结果依赖前面随机产生的考生分布。我的处理方法是在分配结束后做一次冲突检查：把考场号和老师对应的班级、该考场里实际存在的班级做一个关联，一旦匹配上就说明冲突。
SELECT a.room_no, a.main_teacher, t.class_id AS teacher_class FROM #assign_duty a LEFT JOIN dbo.teachers t ON a.teacher_id = t.teacher_id LEFT JOIN dbo.students s ON s.class_id = t.class_id AND s.room_no = a.room_no WHERE s.student_id IS NOT NULL;查出冲突以后，把该老师与另一个同教研组、且不冲突的老师交换考场，人工改两行数据就行。窗口函数把90%的编排工作自动化，剩下几条硬约束由人收尾，这个工作方式我用了好几年，效率反而最高。
5. 排考实测遇到的问题与细节优化
5.1 随机结果不稳定：先固化快照再分发
窗口函数里只要出现 NEWID()，每次执行结果都不一样。排考名单一旦确定就必须固定，不能今天生成一个版本、明天刷新又变了。我自己的习惯是先把随机结果固化到临时表：
SELECT student_id, class_id, NEWID() AS seed INTO #random_seed FROM dbo.students;后面所有 ORDER BY 都用这张临时表里的 seed，而不是直接调用 NEWID()。这样即使反复修改SQL，只要不重新生成临时表，结果就完全稳定。排考名单打印出去以后，万一要复核，也能正确复现当初那份名单。
5.2 取模运算的边界和溢出坑
取模运算的标准写法是 (序号 - 1) % 数量 + 1，不是序号 % 数量。因为 MOD 返回0到数量-1，直接取模会得到0号考场，必须减1再回加1。这个细节在考试规模下虽然只影响少部分人，但一旦出错就是考场号整体错位。
另一个坑是 ABS(CHECKSUM(NEWID())) 可能溢出。CHECKSUM 可能返回 int 的最小值 -2147483648，对这个值取绝对值会超出 int 范围，报错或产生异常随机数。我一直用 ROW_NUMBER() OVER (ORDER BY NEWID()) 代替 CHECKSUM 生成随机偏移，既能打乱顺序又不会溢出。
5.3 考场数计算中的整除陷阱
SQL Server 的整数除法会直接舍去小数。COUNT(*) 和 @roomSize 都是 int 时，1199/30 的结果是39，不是39.97，导致考场数少算一个。正确写法是用浮点转换，或者用“总数+容量-1”再整除：
SET @roomCount = (SELECT (COUNT(*) + @roomSize - 1) / @roomSize FROM dbo.students);这个公式等价于向上取整，而且不用转换类型，我日常更喜欢这种写法。如果考场总数算错，后面所有取模结果都会跟着错，这一行值得看一眼。
5.4 窗口函数别忘索引，也别用函数包字段
数据量只有千把人时，窗口函数性能完全不是问题。但如果考生规模到几万，或者需要反复跑分配用例，索引就很重要。按 class_id 分配时，SQL Server 需要按班级分组排序，这时候建一个覆盖索引收益明显：
CREATE NONCLUSTERED INDEX IX_students_class ON dbo.students(class_id, student_id) INCLUDE(student_name, grade);另一个细节是窗口函数 ORDER BY 里尽量别包函数。比如 ORDER BY CAST(student_id AS VARCHAR) 这种写法会让索引失效。如果学号本来就不是连续数字，建议单独存一列可排序编码，不要在执行窗口函数时临时转换。
5.5 尾考场、异容量考场与交付前的三条检查
尾考场人数不足30的时候，座位号照常按1到实际人数排，不要为了凑数去挪人。打印门贴时把“考场容量”改成实际人数即可。如果学校考场容量不统一，比如有些机房只能坐24人，就不要用固定的 @roomSize，而是先建一张考场容量表，再用累计窗口函数去匹配容量区间，SQL写起来长一点，但思路和本文一致。
最后分享一个我每次交付前都会跑的“三步检查”。第一，人数分布检查，看每个考场人数是否合理；第二，同班同考场检查，确认没有同班扎堆；第三，班主任冲突检查，看有没有老师监考自己班。这三条SQL全部基于前面生成的临时表，运行只要几十秒。检查通过再导出Excel，一份干净、稳定、没人挑毛病的考场名单就出来了。
排考这件事，说到底就是“均匀”和“隔离”两个目标的平衡。PARTITION BY 帮我完成了90%的自动分配，剩下的人工收尾在可控范围之内。这套逻辑我连续用了四五个学期，从月考到期中期末，每次只需要换数据源，改一两个字段名，30分钟以内出名单。做教务系统的朋友，值得把它沉淀成一个存储过程，下次调用会更省事。
