宿舍管理系统数据库怎么选？我踩过坑后的实在建议
去年帮一个职院做宿舍分配系统，需求会上有人张口就说要上 MongoDB 加分库分表。我当时差点笑出声。一个校区一万八千人，床位数据撑死四万行，分什么库分什么表。数据库选型这事儿，最怕的就是不看自己的数据长什么样，直接抄大厂方案。
宿舍这块的数据有几个很明显的脾气。数据量小得可怜，一所三万人规模的高校，床位表三万行，房间表五千行，住宿记录一年新增三万条，攒十年也就三十万行。这体量对 MySQL 来说连热身都算不上。但它的关系特别密，学生挂在床位下，床位挂在房间下，房间挂在楼栋下，还要串起院系、辅导员、宿管员。更麻烦的是约束硬，一张床同一时间只能睡一个人，这条线一旦破了，学生拎着行李站在门口，你就等着挨骂吧。
宿舍数据的三个真实特点
我把经手过的几个项目复盘了一遍，宿舍数据的画像基本固定：
- 总量小：单校区床位通常几千到几万，十年数据量也难破百万行
- 关系强：学生、床位、房间、楼栋、院系之间全是外键，随便一查就要三四个表关联
- 并发极端：平时宿管科一天查几十次报表，选宿舍那两天峰值能冲到每秒几百个请求
我见过一个学校用 MongoDB 存床位分配，文档里嵌套了整个房间的床位数组。结果开放选房当天，两个学生分到了同一张床。原因很简单，Mongo 默认不做唯一约束，两个人同时读到"这床空着"，然后各自写回。后来他们在 beds 集合上补了唯一索引，又拿 Redis 的 SETNX 加了一层锁，才把问题摁住。这活儿要是放在 MySQL 里，一个唯一索引就完事了，根本不用绕这么大弯。
我的选型顺序和踩过的坑
如果让我重新排一遍，我会这么走：
- 床位不到五千、就一台机器跑，SQLite 完全够，备份就是复制一个文件，宿管老师自己都会操作
- 绝大多数高校场景，MySQL 8 或者 PostgreSQL 直接上，四核八G 单机能撑到这批学生毕业
- 选宿舍那种抢票式的高并发，别指望数据库硬扛，Redis 做空床位缓存加分布式锁，数据库只负责落库
- 学校信息中心只会 SQL Server，那就跟着他们走，运维能力比理论性能重要一百倍
- 文档型数据库慎碰，除非你确定不需要事务和强关联
有个细节很多人忽略：调宿、退宿、休学保留床位这些操作会产生大量状态变更。我习惯给住宿记录表加一列版本号，更新时带上版本条件，配合乐观锁处理并发修改。实测下来，比一把大锁卡住整张表要顺得多。之前那个职院项目，选房高峰每秒四百多请求，MySQL 单机 CPU 跑到六成，页面响应一直压在两百毫秒以内，压根没用上读写分离。
还有报表。宿管科每年要出空床位统计、院系住宿率、退宿原因分析，这些全是典型的聚合查询。MySQL 的 group by 加索引优化器处理起来很轻松，换成 Mongo 的聚合管道，写起来能把人逼疯。这也是我坚持关系型的一个私心。
说到底，宿舍数据库选型不是比谁的架构高级，是比谁更贴合业务。数据量小、关系紧、约束硬、平时冷清开学爆，这四条摆在这，答案其实已经很清楚了。先算清楚你的床位总数和峰值并发，再决定要不要上那些花哨的东西，顺序反过来准出错。