酒店管理系统数据库设计：表结构、事务与并发控制实践

简介一份面向数据库课程设计的酒店管理系统客房管理Java 项目适合正在完成数据库实训作业的学生或需要快速验证客房业务数据建模的开发者参考。资源围绕客房、客户、订单、入住与退房等核心数据实体完整演示了从关系型数据库如 MySQL 或 SQL Server表结构设计、主外键约束、数据类型规划到 JDBC 增删改查的建模思路可帮助理解数据库原理在真实酒店业务中的落地方式。压缩包共 30 个文件包含 18 个 class 编译文件、10 个 Java 源码和 2 张 JPG 图片整体仅 404KB轻量易用源码覆盖预订、入住、退房、结账、客户查询与登记等模块class 文件便于直接运行验证Java 源码适合阅读与二次修改图片可配合理解界面设计。已有 1874 人学习下载。借助本项目可掌握酒店客房场景下的关系表设计、Java 图形界面与数据库的交互编码套路同时理解订单状态随入住、退房流程更新的处理逻辑以及测试数据准备、超期未退房等异常情况的排错思路是一份能快速上手并完成课程设计报告的实用参考资料。1. 酒店管理系统数据库课程设计里最像“真实业务”的一道题如果你的课程设计题目落到“酒店管理系统客房管理”上恭喜你拿到了一个最接近真实业务的数据库课设题目。这个题目拼的从来不是界面有多漂亮而是房间状态从“空闲→已预订→入住中→已退房”这一整条链路能不能在数据库层面闭环。很多人写完增删改查就去交差了结果答辩时被一句“两个客人同时订最后一间房怎么办”问翻车。这篇文章直接给可落地的表结构、连接配置和事务写法也把常见踩坑列出来。适合正在做数据库课程设计或毕业设计的学生也适合想快速搭一套客房管理原型做二次开发的从业者。2. 从 ER 图到关系模式把酒店客房业务拆成可落地的表结构2.1 客房、房型、房态分表还是合表先想清楚状态流转很多同学一开始就把“房间号、房型、价格、状态”全塞进一张 room 表这是民宿小账本的做法。真正常见的酒店管理系统实践至少会把“房型”和“房间”拆成两张表房型表存的是可复制的基础属性比如大床房、双床房、门市价房间表存的是物理存在的一间房它属于哪个房型、在哪一层、现在是什么状态。为什么必须拆因为一间“豪华双床房”可以有很多间而“房间状态”属于每一间独立房间的动态数据。如果不拆改一次房型门市价要更新十几行而且很容易出现同一栋楼里两个房间价格不一致的脏数据。两张表的职责分别是“房型定义”和“房间实例”这也是你在答辩里解释 ER 图时最容易讲清楚的一点。房间的状态字段常见做法是用一个 TINYINT 表示0 空闲、1 已预订、2 入住中、3 维修、4 打扫中。有人喜欢用 VARCHAR 存“已入住”“空闲”看起来直观但代码判断、索引效率、排序都不如数字类型。更重要的是这个字段只代表“当前状态”它没有历史。真正常见的酒店管理系统无论连锁还是单体酒店都会配套一张状态流水表记录 RoomNo、旧状态、新状态、操作人、操作时间。这套设计放到“智慧酒店管理系统”方向尤其有价值。房间状态每变一次就插入一条流水一旦出现价格争议、清洁纠纷、门锁联动你能直接查出“这间房昨天 17:30 从入住中变成了打扫中操作人是谁”。课程设计阶段把这个日志表建出来比任何花哨页面都加分。下面是一个最小字段的房态流转日志表参考。字段类型说明log_idINT UNSIGNED AUTO_INCREMENT主键room_idINT UNSIGNED关联房间表old_statusTINYINT变更前状态new_statusTINYINT变更后状态operatorVARCHAR(50)操作人remarkVARCHAR(255)备注换房、维修等信息create_timeDATETIME变更时间2.2 客户表与订单表外键怎么设才能避免删不掉、改不动客房业务的核心人物是“客户”核心单据是“订单”和“入住登记”。我一般建议至少做三张表客户表 customer、预订订单表 booking_order、入住登记表 check_in_record。客户表存客户基本信息订单表存一次预订行为的计划日期和状态入住登记表存每一次实际住店的流水。这三张表的关系是一个客户可以有多张订单一张订单可以关联一次入住登记。外键设计是课程设计里最纠结的地方。物理外键能让数据库层面保证引用完整性但代价是删除和更新路径非常受限。比如你做了“客户表→订单表”的物理外键测试阶段想清空订单重新造数据就得先删订单再删客户顺序反了就报错如果删了一个有过历史订单的客户数据库会直接拒绝因为历史订单还引用着他。更现实的做法是主外键关联字段照建但把“业务里唯一且有意义的字段”单独做唯一索引而不是把外键当作唯一身份。比如房间号 room_no 建唯一索引但订单表不直接引用 room_no而是引用 room_id 自增主键客户身份证号建唯一索引但订单表引用 customer_id。这样既保证数据可追踪又不会因为业务键修改导致外键链断裂。课程设计答辩时老师问到外键设计你可以明确说核心表之间保留逻辑外键应用层用事务保证一致性物理外键只用于强制不能丢失引用关系的场景比如入住登记与订单。订单表里有一个容易被忽略的字段下单时的房价快照。后文会专门讲它为什么必须存在。这里先记住一条原则凡是订单级别的信息存订单表凡是客户资料级别的信息存客户表凡是房间物理属性的信息存房间表。不要为了省一次联表查询而把客户手机号、房型名称全冗余进订单表。2.3 范式与反范式为什么订单表里要冗余“房价快照”讲范式不是为了背概念是为了让别人问不出你的毛病。第三范式说非主属性不能传递依赖于主键。房型的门市价本质上是房型表的属性它通过 RoomID→TypeID→BasePrice 这条链路和订单发生关系。如果订单表里也存了“当前房价”订单的最终金额就和房型当前的挂牌价建立了传递依赖这违反了第三范式。但酒店业务里有个现实需求客人下单时的价格必须锁定。客人 3 月 1 日以 388 元订了 3 月 10 日的房3 月 8 日酒店把门市价调到了 488 元你不能让客人退房时按 488 结账否则就是价格欺诈。所以订单表里必须冗余一个“下单时房价快照”。这个冗余是业务必须属于反范式设计。反范式有一个边界你冗余的必须是“下单那一刻就不再变化”的快照数据而不是“会跟着源表变化”的关联数据。把房价快照放进订单表没问题把客户手机号放进订单表就有隐患——客户改手机号后所有历史订单里的旧号码不会同步更新查询时就只能拿到过期信息。真正常见的做法是订单表只存 customer_id需要显示手机号时联表查客户表但订单表一定要存 room_price_snapshot因为成交价已经成为这笔订单的既定事实。把一张错误的订单表结构写成反例你会更容易理解插入、更新、删除异常是怎么发生的如果订单表直接存了客户姓名和客户手机号那么一个新客户只要还没下单就无法被记录在系统里这是插入异常一个客户改了手机号必须去更新所有历史订单否则旧订单上的联系方式是错的这是更新异常删除一笔订单时客户信息也跟着被删掉了这是删除异常。你的关系模式拆开后这三类异常自然消失数据库课程设计的分值也就在这里拉开。3. 建库建表与连接配置MySQL 与连接池的常见做法3.1 一张完整的建表 DDL字符集、引擎与索引一次配齐数据库选型上课程设计最常用的是 MySQL免费、资料多、Navicat 和命令行都能连。下面这套 DDL 是我平时搭客房管理原型时习惯使用的结构足够支撑后续所有业务。字符集直接选 utf8mb4不要选 utf8因为 MySQL 的 utf8 实际不是完整的四字节 UTF-8遇到生僻字或 emoji 会报乱码和截断错误。CREATE DATABASE IF NOT EXISTS hotel_manage DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; USE hotel_manage; CREATE TABLE room_type ( type_id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, type_name VARCHAR(50) NOT NULL, base_price DECIMAL(10,2) NOT NULL, bed_type VARCHAR(20) DEFAULT NULL, max_guests TINYINT NOT NULL DEFAULT 2, UNIQUE KEY uk_type_name (type_name) ) ENGINEInnoDB; CREATE TABLE room ( room_id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, room_no VARCHAR(10) NOT NULL, type_id INT UNSIGNED NOT NULL, floor TINYINT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0空闲 1预订 2入住 3维修 4打扫, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_room_no (room_no), KEY idx_type (type_id), KEY idx_status (status) ) ENGINEInnoDB; CREATE TABLE booking_order ( order_id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL, customer_id INT UNSIGNED NOT NULL, room_id INT UNSIGNED NOT NULL, check_in_date DATE NOT NULL, check_out_date DATE NOT NULL, order_status TINYINT NOT NULL DEFAULT 0 COMMENT 0预订 1入住 2完成 3取消, room_price_snapshot DECIMAL(10,2) NOT NULL COMMENT 下单时房价快照, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no), KEY idx_customer (customer_id), KEY idx_status_date (order_status, check_in_date) ) ENGINEInnoDB; CREATE TABLE check_in_record ( record_id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_id INT UNSIGNED NOT NULL, room_id INT UNSIGNED NOT NULL, customer_id INT UNSIGNED NOT NULL, actual_check_in DATETIME NOT NULL, actual_check_out DATETIME DEFAULT NULL, amount_paid DECIMAL(10,2) DEFAULT 0.00, operator VARCHAR(50) DEFAULT NULL, KEY idx_order (order_id), KEY idx_room_time (room_id, actual_check_in) ) ENGINEInnoDB;逻辑说明这里把业务键和主键分开了。订单对外展示用 order_no比如H20250301001方便人工识别内部关联用自增主键 order_id避免订单号生成逻辑影响表关联。房间表也一样room_no 加唯一索引保证不重号但订单表引用 room_id这样以后调整房间编号格式时不需要改历史订单。参数说明DECIMAL(10,2) 存金额一共 10 位有效数字小数点后 2 位足够覆盖房费计算状态字段用 TINYINT比 VARCHAR 省空间且判断快update_time 用 ON UPDATE CURRENT_TIMESTAMP应用层不用手动维护。选 InnoDB 而不是 MyISAM 是最关键的决定InnoDB 支持事务和行级锁MyISAM 只支持表级锁并发一上来会互相阻塞这也是常见的数据库优化起点。如果你换达梦、PostgreSQL 等数据库自增写法会略有差异但表结构设计思路是通用的。3.2 连接池参数为什么并发一上来连接就崩课设阶段最常见的连接错误是每次操作都现场DriverManager.getConnection()用完再 close。这在单人调试时没问题一旦用 JMeter 或浏览器并发点几下数据库就会报连接超时、Too Many Connections。原因是建立连接要握手、认证、建会话开销远比执行一条 UPDATE 大。真正常见的做法是引入连接池让连接创建一次后反复复用。以 Druid 为例给出一个常见配置。如果你用的是 HikariCP参数名略有不同但核心逻辑一致。# druid 连接池配置 spring.datasource.urljdbc:mysql://localhost:3306/hotel_manage?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue spring.datasource.usernameroot spring.datasource.password你的密码 spring.datasource.driver-class-namecom.mysql.cj.jdbc.Driver spring.datasource.typecom.alibaba.druid.pool.DruidDataSource spring.datasource.druid.initial-size5 spring.datasource.druid.min-idle5 spring.datasource.druid.max-active20 spring.datasource.druid.max-wait5000 spring.datasource.druid.validation-querySELECT 1 spring.datasource.druid.test-while-idletrue参数说明initial-size 是启动时预创建的连接数5 条足够课程设计场景min-idle 是池里至少保留的空闲连接数max-active 是上限超过之后新请求要排队等待max-wait 是排队等待时间单位毫秒5000 毫秒内拿不到连接就直接抛异常。max-active 不必调太大20 已经很充裕因为连接池会把同一连接复用到多个请求。validation-query 是保活检查语句空闲连接被回收前先执行SELECT 1确认连接没断。连接串里有三个参数必须说清楚。characterEncodingutf8 保证中文不乱码serverTimezoneAsia/Shanghai 解决 8 小时时差useSSLfalse 是本地开发环境没必要做 SSL 加密。allowPublicKeyRetrievaltrue 是新版 MySQL 驱动在 caching_sha2_password 认证方式下连接时需要的参数不加会报 Public Key Retrieval is not allowed。如果你用 Navicat 连接达梦数据库驱动和 URL 格式完全不同但连接池的复用思路不变排查方向也一致先从命令行确认数据库服务本身能不能连上再看连接串参数。3.3 三层结构与事务边界SQL 该写在 DAO 层还是 Service 层客房管理系统的代码结构如果所有 SQL 都写在 Controller 里事务会变得难以控制。常见做法是分三层Controller 做参数校验和返回结果Service 做业务规则和事务边界DAO 只负责单表读写。以入住登记为例业务规则是“先确认房间空闲再插入入住记录”这两步必须在同一个事务里否则会出现房间状态已改但记录没写进去的脏数据。Spring 事务用起来最简单在 Service 方法上加Transactional注解。下面这段代码模拟了入住登记的三个必要步骤。Service public class CheckInService { Autowired private RoomMapper roomMapper; Autowired private OrderMapper orderMapper; Autowired private CheckInRecordMapper checkInRecordMapper; Transactional(rollbackFor Exception.class) public void checkIn(Integer orderId, Integer roomId, String operator) { // 第一步用条件更新抢房间状态受影响行数必须为 1 int updated roomMapper.freeToChecked(roomId); if (updated ! 1) { throw new BusinessException(房间已被占用或当前状态不允许入住); } // 第二步把订单状态从“预订”改为“入住中” orderMapper.updateStatus(orderId, 1, 0); // 第三步写入入住登记流水 checkInRecordMapper.insert(orderId, roomId, operator); } }逻辑说明rollbackFor Exception.class的意思是方法里任何一个步骤抛出异常前面已执行的操作全部回滚。第一步的 freeToChecked 对应的 SQL 类似UPDATE room SET status2 WHERE room_id? AND status0它既是状态修改也是并发控制。如果两个请求同时操作同一间房只有先拿到行锁的那个事务能把这行从 0 改成 2另一个请求受影响行数为 0直接抛异常回滚。参数说明updateStatus 方法第二个参数 1 是新状态第三个参数 0 是旧状态条件。更新订单时带上旧状态条件是为了防止同一张订单被重复办理入住。三步操作的顺序是固定的先锁房间行再改订单最后插入流水。所有事务里都保持这个顺序能避免多个事务互相等待对方持有的锁而产生数据库死锁。如果你不做分层把这些逻辑全塞进 JSP 或 Servlet事务管理会让你极其痛苦而且答辩时讲不清楚。4. 客房管理的增删改查从入住、退房到换房的事务实践4.1 入住登记用“条件更新”代替“先查后改”来防并发数据库增删改查的“增”在客房管理里不是简单 INSERT而是 INSERT 之前必须验证房间状态。最直观也最容易翻车的写法是先 SELECT 房间状态如果等于 0再 INSERT 订单最后 UPDATE 房间状态。问题在于 SELECT 和 UPDATE 之间有两个时间窗口两个连接都能读到“空闲”然后都执行成功房间被重复预订。常见做法是把整个流程放进一个事务用“条件更新”作为并发闸门。下面给出存储过程版本的完整流程逻辑直观也方便你在答辩时演示。DELIMITER // CREATE PROCEDURE sp_check_in ( IN p_order_id INT, IN p_room_id INT, IN p_operator VARCHAR(50), OUT p_result INT ) BEGIN DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; SET p_result -1; END; START TRANSACTION; UPDATE room SET status 2, update_time NOW() WHERE room_id p_room_id AND status 0; IF ROW_COUNT() 1 THEN ROLLBACK; SET p_result -2; ELSE UPDATE booking_order SET order_status 1 WHERE order_id p_order_id AND order_status 0; INSERT INTO check_in_record(order_id, room_id, actual_check_in, operator) VALUES(p_order_id, p_room_id, NOW(), p_operator); COMMIT; SET p_result 0; END IF; END // DELIMITER ;逻辑说明第一步的UPDATE room ... WHERE room_id? AND status0是控制并发的关键。InnoDB 会对满足条件的行加锁两个事务同时执行时后到的事务会被阻塞等前一个事务提交后才能继续这时它发现 status 已经不是 0ROW_COUNT() 返回 0整个事务回滚。第二步把订单从“预订”改成“入住中”也带了AND order_status0防止同一订单被重复提交。第三步插入入住流水如果插入失败事务回滚房间状态也会被还原。参数说明p_result 是输出参数调用方通过它的值判断结果0 表示成功-1 表示数据库异常-2 表示房间状态已被占用。存储过程里 START TRANSACTION 和 COMMIT/ROLLBACK 必须配套注意 EXIT HANDLER 负责捕获 SQL 异常并回滚避免部分提交。4.2 退房结账用 DECIMAL 计算费用避免金额“差一分”退房是“更新型”业务核心问题是费用计算。房费按晚数计算3 月 1 日入住、3 月 3 日退房按两晚计算如果订单里还有加床费、餐费、洗衣费等应该走一张消费明细子表这里为了讲清边界先简化成额外费用入参。金额计算必须重视数据类型。数据库字段用 DECIMAL(10,2)应用层用 BigDecimal不能用 double 或 float。这不是玄学而是 IEEE 754 浮点数无法精确表示大部分十进制小数0.1 加 0.2 在 float 里会变成 0.30000000000000004账单一旦累计就会差一分钱。课程设计里用 float 算钱翻车的案例比比皆是。Transactional public BigDecimal checkout(Integer orderId, BigDecimal extraFee, String operator) { // 查订单拿到房间号、房价快照、计划入住和退房日期 Order order orderMapper.getById(orderId); if (order.getOrderStatus() ! 1) { throw new BusinessException(订单状态不是入住中不能退房); } // 按晚数计算房费不足一晚按一晚 long nights ChronoUnit.DAYS.between( order.getCheckInDate(), order.getCheckOutDate()); if (nights 1) { nights 1; } BigDecimal roomFee order.getRoomPriceSnapshot() .multiply(BigDecimal.valueOf(nights)); BigDecimal total roomFee.add(extraFee); // 回写入住登记表的实际离店时间和结清金额 checkInRecordMapper.finish(orderId, LocalDateTime.now(), total, operator); // 订单置为已完成 orderMapper.updateStatus(orderId, 2, 1); // 房间置为“打扫中”而不是直接回到空闲 roomMapper.updateStatus(order.getRoomId(), 4, 2); return total; }逻辑说明房费必须用订单冗余的 room_price_snapshot而不能去查房型表当前的门市价。客人下单后酒店调价是酒店经营行为不能追溯到已成交的订单上。最后一步把房间置为“打扫中”而不是直接置为“空闲”是因为客房需要保洁检查后才能再次出售这是酒店业务里的硬规矩。参数说明ChronoUnit.DAYS.between计算两个日期之间的天数差适用于按整晚计费的场景。roomMapper.updateStatus(roomId, 4, 2)的第三个参数 2 是旧状态条件确保只有“入住中”的房间才能被置为“打扫中”避免误操作一个空闲房间。extraFee 如果有值在真实系统里应该由消费明细子表汇总而来而不是前端随便传一个数课设阶段可以加上最小金额和最大金额的前端校验。4.3 换房与预订取消状态机里不能违背的几条铁律换房本质上是“旧房间退房 新房间入住”的组合操作。它必须在一个事务里完成否则会出现旧房已释放、新房未入住或者新房已入住、旧房未释放的中间状态。常见做法是事务开始先改旧房间状态为“空闲”再改新房状态为“入住中”同时更新订单里的 room_id最后插入一条换房流水。预订取消是另一个容易写错的地方。一个订单只有处于“预订”状态时才能取消已经“入住”的订单只能走退房流程不能取消后把房间直接释放。对应到 SQL取消操作必须带状态条件UPDATE booking_order SET order_status 3 WHERE order_id 5 AND order_status 0; UPDATE room SET status 0, update_time NOW() WHERE room_id 3 AND status 1;逻辑说明第一条语句把订单从“预订”改成“取消”条件是order_status 0第二条把房间从“已预订”改成“空闲”条件是status 1。两条都执行成功才能提交。如果其中一条的受影响行数为 0说明在这个事务开始前订单或房间的状态已经被其它事务改变必须整体回滚否则会出现“订单取消成功但房间仍被占用”或“房间已释放但订单依然是预订状态”的问题。参数说明这里的 5、3、3、0、0、1 都是示例参数实际项目里参数从接口传入。建议把所有状态流转先画成一张简单的状态表空闲可以到预订和入住预订可以到入住和取消入住只能到退房退房只能到打扫。凡是状态表里没有的跳转应用层一律拒绝。5. 课设避坑指南字符集、锁、外键与时区的 5 个翻车现场5.1 乱码插入的“入住人姓名”变成问号现象网页上输“张伟”数据库里存的是“????”或者英文正常、中文全变问号。原因字符集在三个位置不一致数据库、客户端工具、JDBC 连接串。最常见的是建库时用了默认 latin1或者连接串里漏了characterEncodingutf8。解决建库时用 utf8mb4连接串加useUnicodetruecharacterEncodingutf8。如果库已经建了执行一条修改语句即可ALTER DATABASE hotel_manage CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;注意修改数据库字符集不会自动改已有表的字符集已存在的表还要单独改。另外配置文件里写characterEncodingutf8而不是utf8mb4是正常的因为 MySQL 驱动会把 utf8 映射为 utf8mb4但建库语句里应写 utf8mb4。5.2 删除失败明明房间退房了房间记录却删不掉现象管理员想删一间测试用的房间执行 DELETE 时报错Cannot delete or update a parent row: a foreign key constraint fails。原因booking_order 或 check_in_record 表还有记录引用了这个 room_id。只要有历史入住流水房间就是一个已经发生的事实数据库外键不允许你直接删掉它。解决不要试图删除房间。正确做法是给房间增加一个“停用”状态比如 status 设为 5表示不再接受新预订但历史流水仍然可查。如果只是测试阶段想清库应该按依赖顺序清理先删 check_in_record再删 booking_order最后才能删 room。课程设计答辩时你能说出“房间是基础数据业务上线后只停用不删除”比硬删数据更显得懂行。物理外键不一定要去掉但要理解它的限制。5.3 时差查询结果的日期总是差 8 小时现象入住时间是下午 14:00查出来变成早上 06:00或者反过来所有日期时间整体偏移 8 小时。原因MySQL 驱动和数据库服务端时区不一致。最常见的是连接串里没有指定 serverTimezone驱动用了 JVM 默认时区而 MySQL 服务端配置的 time_zone 是 UTC。解决连接串加serverTimezoneAsia/Shanghai。如果改完还有问题执行 SQL 看数据库侧时间SELECT NOW();如果数据库返回的时间和系统当前时间差 8 小时可能是服务器时区配置问题用SET GLOBAL time_zone 08:00修正。排查时先在命令行里直接执行SELECT NOW()确认数据库本身时间是否正确再查连接参数能快速缩小范围。5.4 超卖两个人同时抢到最后一件客房现象并发测试中两个订单同时预订同一间房系统都提示预订成功最后房间里只有一个客人另一个订单变成无效订单。原因代码逻辑是“先 SELECT 房间状态再用 INSERT 生成订单最后 UPDATE 房间状态”。两个连接都读到 status0于是都生成订单房间状态被后执行的 UPDATE 覆盖为已预订但两个订单都已插入数据不一致。解决把“状态变更”作为并发控制点。用条件更新UPDATE room SET status 1 WHERE room_id 10 AND status 0;如果返回受影响行数为 1说明抢锁成功这个连接才能继续插入订单如果返回 0说明房间被别人抢先直接拒绝。注意 InnoDB 下行级锁才能这样控制MyISAM 虽然不会出现这个问题但它用表锁并发性能差不建议用于酒店管理系统这类需要并发的场景。另外多个事务的锁顺序要统一建议都按“room → booking_order → check_in_record”的顺序拿锁避免死锁。5.5 结算误差用 float 算钱账单永远差一分现象房费、餐费、洗衣费单独算都对加总后和应收金额差 0.01 元或者单价 0.6 小时计算后出现 0.6000000000000001。原因float/double 是二进制浮点数无法精确表示十进制小数。金额计算用 float 是课程设计的高频血泪错误。解决数据库字段全部用 DECIMAL(10,2)Java 代码里用 BigDecimal接收前端金额参数时直接用 String 或 BigDecimal不要先转 double 再转 BigDecimal。计算时先乘后除中间不要四舍五入。比如按小时计费时单价乘以时长后保留两位小数即可不需要每一步都 round。6. 验证与进阶用一个模拟脚本证明你的系统撑得住七天运营6.1 生成七天运营数据验证房态流转的一致性课程设计答辩时老师最爱做的动作是打开数据库看你的表里有没有真实可信的数据。只插两条测试记录不够最好用脚本生成连续七天的预订和入住数据。下面给出一种用 MySQL 8 的递归 CTE 和随机函数生成模拟订单的写法适合在开发环境造数据。WITH RECURSIVE dates AS ( SELECT 2025-03-01 AS d UNION ALL SELECT DATE_ADD(d, INTERVAL 1 DAY) FROM dates WHERE d 2025-03-07 ) INSERT INTO booking_order(order_no, customer_id, room_id, check_in_date, check_out_date, order_status, room_price_snapshot, create_time) SELECT CONCAT(T, DATE_FORMAT(d, %Y%m%d), LPAD(room.room_id, 3, 0)), customer.customer_id, room.room_id, d, DATE_ADD(d, INTERVAL 1 DAY), 2, room_type.base_price, NOW() FROM dates CROSS JOIN (SELECT room_id FROM room ORDER BY RAND() LIMIT 10) room CROSS JOIN (SELECT customer_id FROM customer ORDER BY RAND() LIMIT 1) customer;逻辑说明这个脚本生成 7 天内每天 10 间房各一条已完成订单订单状态直接置为 2。它只为统计演示服务没有模拟完整的入住和退房流水。在你自己的验证环境里更完善的做法是写一个存储过程循环生成订单、调用第四章的入住流程、再调用退房流程让每一单都走完完整状态流转。参数说明ORDER BY RAND() LIMIT 10是随机取房间课设造数没问题数据量大了之后会全表扫描生产系统不要这样用。DATE_ADD(d, INTERVAL 1 DAY)表示每人只住一晚你可以改成 2 天、3 天来模拟不同房晚分布。6.2 用统计 SQL 自测入住率与收入能不能对得上数据造完不代表系统正确要用统计 SQL 对账。第一个验证是“订单状态已完成的订单必须都有对应的退房记录”。如果两者数量不一致说明退房服务的更新逻辑有遗漏SELECT (SELECT COUNT(*) FROM booking_order WHERE order_status 2) AS finished_orders, (SELECT COUNT(*) FROM check_in_record WHERE actual_check_out IS NOT NULL) AS checked_out_records;第二个验证是检查房间状态运行一段时间后所有空闲房间的 status 都应该是 0。如果出现 status 为 1 或 2 但没有对应未完成订单的房间就是脏数据SELECT room_id, room_no, status FROM room WHERE status IN (1, 2) AND room_id NOT IN ( SELECT room_id FROM booking_order WHERE order_status IN (0, 1) );这两个查询的思路是“数据自洽”业务状态之间必须能对上账。把统计 SQL 放进答辩演示里老师能直接看到你的系统经过七天模拟运营后数据仍然一致这比口头说“我测试过”有说服力得多。我当年做课设时吃过“先查再改”的亏后来养成一个习惯凡是涉及房态变化的代码都要在 WHERE 里带上旧状态条件每跑一次模拟数据就用对账查询把所有状态数一遍。答辩前一周我把每个状态流转的 SQL 打印出来贴在电脑边上老师问到哪一步就能立刻讲出对应语句。这个习惯后来带进了工作帮我挡掉不少线上问题。希望帮到你。本文还有配套的精品资源点击获取