简介这份资源是《酒店住宿管理系统的设计与实现》毕业设计文档面向计算机相关专业学生及需要完成管理信息系统课程设计的学习者帮助解决从需求分析到系统测试全流程的写作与开发参考问题。压缩包内共1个doc文件约1.61MB完整呈现论文结构。文档围绕B/S架构展开涵盖HTML、JavaScript、JSP与MySQL等关键技术并系统梳理了客房管理、财务管理、订单管理、管理员管理四大功能模块的设计思路同时包含架构概述、开发环境说明、可行性分析、界面与代码实现及测试用例等内容。目前已有109人学习适合需要参考选题背景、技术选型、数据库设计及论文框架的读者可据此快速理清毕业设计的写作脉络与功能模块划分也可作为同类管理信息系统开发的对照模板。1. 酒店住宿管理系统的设计与实现从一张入住登记表到能跑通的 JSP 工程酒店前台最怕的不是满房而是凌晨两点一位客人拿着房卡说“我房间已经有人住了”。这种事故九成不是服务员粗心而是住宿管理系统在房态同步、订单状态流转上留了缝。所谓酒店住宿管理系统本质是把“预订—入住—换房—退房—夜审”这条链路用数据库事务锁死让每一间房在任意时刻只有一个确定状态。它适合两类人一是要做课程设计或毕业设计的学生需要一套能演示、能答辩、代码量可控的方案二是中小型酒店或民宿的自建需求预算有限、不想上重型 PMS。常见技术选型是 JSP Servlet MySQL前端用 HTML/JavaScript 渲染这套组合虽然老但部署简单、资料多、排错直观对单店几十到上百间房的体量完全够用。下面按“先立住数据模型再跑通入住退房最后处理并发和夜审”的顺序讲透。2. 先把房态和订单的数据模型定死三张表撑起整个系统2.1 为什么房间、房型、订单必须拆成三张表很多人一上来就画一张room表把房号、价格、入住人、入住时间全塞进去结果换房时要么丢历史要么把旧记录覆盖掉。正确做法是拆成三张核心表room_type房型管价格和床位描述、room物理房间管房号和当前状态、order订单管客人、时间、金额。房态不存“空闲/占用”这种会变的字段到room里当唯一依据而是由订单的checkin_time和checkout_time反推room只保留一个status做快速筛选。-- 房型表价格挂在这里不挂房间 CREATE TABLE room_type ( id INT PRIMARY KEY AUTO_INCREMENT, type_name VARCHAR(32) NOT NULL, -- 大床房/标间 price DECIMAL(10,2) NOT NULL, -- 门市价 bed_count TINYINT DEFAULT 1 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 房间表只存物理属性和当前状态 CREATE TABLE room ( id INT PRIMARY KEY AUTO_INCREMENT, room_no VARCHAR(8) NOT NULL UNIQUE, -- 如 8801 type_id INT NOT NULL, status TINYINT DEFAULT 0, -- 0空闲 1已入住 2待打扫 3维修 FOREIGN KEY (type_id) REFERENCES room_type(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单表时间区间是房态的真正来源 CREATE TABLE order ( id INT PRIMARY KEY AUTO_INCREMENT, room_id INT NOT NULL, guest_name VARCHAR(32) NOT NULL, phone VARCHAR(20), checkin_time DATETIME NOT NULL, checkout_time DATETIME, status TINYINT DEFAULT 0, -- 0预订 1在住 2已退 3取消 amount DECIMAL(10,2), FOREIGN KEY (room_id) REFERENCES room(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;逻辑说明room.status是给前台看板用的冗余字段真正判断某天某房是否可订要查order表里有没有时间区间重叠且状态为 0 或 1 的记录。参数上status用 TINYINT 而不是字符串是为了索引效率checkout_time允许为空表示尚未退房。字符集统一 utf8mb4避免客人姓名里的生僻字或 emoji 存进去变问号。2.2 用 SQL 判断房间在指定日期是否可订前台点“预订”时系统必须回答一个问题这间房从 3 月 5 日到 3 月 8 日有没有冲突。标准写法是区间重叠判断不要用BETWEEN硬套因为退房当天通常可以再入住。-- 查询 room_id5 在 [2025-03-05, 2025-03-08) 是否可订 SELECT COUNT(*) AS conflict FROM order WHERE room_id 5 AND status IN (0, 1) AND checkin_time 2025-03-08 14:00:00 AND (checkout_time IS NULL OR checkout_time 2025-03-05 12:00:00);逻辑说明checkin_time 新退房时间且旧退房时间 新入住时间两个条件同时成立才算重叠。checkout_time IS NULL表示客人还在住必须算冲突。参数上入住时间一般取当天 14:00退房取次日 12:00这是行业惯例写死在配置里比让前台手填更稳。conflict返回 0 才允许下单返回大于 0 就提示“该房型已满建议换房”。提示order是 MySQL 关键字建表和查询时务必用反引号包起来否则在部分版本直接报语法错误这个坑我见过太多次。3. 用 JSP Servlet 跑通入住和退房的最小闭环3.1 入住登记的 Servlet 与事务边界入住不是简单 INSERT 一条订单它要同时改room.status和写订单两个操作必须在一个事务里。JSP 只负责展示表单业务逻辑放 Servlet这是 MVC 的基本纪律也是答辩时老师最爱问的点。// CheckinServlet.java 核心片段 protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { int roomId Integer.parseInt(req.getParameter(roomId)); String guestName req.getParameter(guestName); String phone req.getParameter(phone); Connection conn null; try { conn DBUtil.getConnection(); conn.setAutoCommit(false); // 开启事务 // 1. 再次校验房态防止并发重复入住 PreparedStatement check conn.prepareStatement( SELECT status FROM room WHERE id? FOR UPDATE); check.setInt(1, roomId); ResultSet rs check.executeQuery(); if (!rs.next() || rs.getInt(status) ! 0) { conn.rollback(); resp.getWriter().write({\code\:1,\msg\:\房间不可入住\}); return; } // 2. 写订单 PreparedStatement ins conn.prepareStatement( INSERT INTO order(room_id,guest_name,phone,checkin_time,status) VALUES(?,?,?,NOW(),1)); ins.setInt(1, roomId); ins.setString(2, guestName); ins.setString(3, phone); ins.executeUpdate(); // 3. 改房态 PreparedStatement upd conn.prepareStatement( UPDATE room SET status1 WHERE id?); upd.setInt(1, roomId); upd.executeUpdate(); conn.commit(); resp.getWriter().write({\code\:0,\msg\:\入住成功\}); } catch (Exception e) { if (conn ! null) try { conn.rollback(); } catch (SQLException ex) {} throw new ServletException(e); } finally { if (conn ! null) try { conn.setAutoCommit(true); conn.close(); } catch (SQLException ex) {} } }逻辑说明SELECT ... FOR UPDATE是关键它给这一行加排他锁两个前台同时点同一间房只有一个能拿到锁并继续另一个会阻塞到事务结束再读到status1从而被拒绝。参数上checkin_time用NOW()由数据库生成避免应用服务器和数据库时钟不一致。返回 JSON 而不是跳转页面是为了配合前端 JavaScript 做无刷新提示。3.2 退房结算与房态置为待打扫退房要算钱还要把房间状态改成“待打扫”不能直接置空闲否则保洁没做就被下一个客人订走。金额按实际住店天数乘房型价格天数用DATEDIFF算不足一天按一天。-- 退房更新订单和房态金额按天计算 UPDATE order o JOIN room r ON o.room_id r.id JOIN room_type t ON r.type_id t.id SET o.checkout_time NOW(), o.status 2, o.amount GREATEST(DATEDIFF(NOW(), o.checkin_time), 1) * t.price, r.status 2 WHERE o.id ? AND o.status 1;逻辑说明GREATEST(..., 1)保证当天入住当天退也收一天钱。o.status 1作为条件防止重复退房。参数上?是订单 ID由前端从在住列表传入。执行后受影响行数为 0说明订单状态不对或已被退要提示前台刷新。3.3 前端房态看板用 JavaScript 定时刷新前台看板要实时但没必要上 WebSocket用setInterval每 30 秒拉一次接口就够。JSP 页面里嵌 JavaScript注意数据类型判断接口返回的status是数字别用和字符串混比。// 房态看板轮询30 秒一次 function loadRoomStatus() { fetch(RoomStatusServlet) .then(res res.json()) .then(data { const grid document.getElementById(roomGrid); grid.innerHTML ; data.forEach(room { const div document.createElement(div); // 严格判断类型避免 0 0 的隐式转换坑 const statusMap {0: 空闲, 1: 在住, 2: 待打扫, 3: 维修}; div.className room-cell status- Number(room.status); div.textContent room.roomNo statusMap[Number(room.status)]; grid.appendChild(div); }); }) .catch(err console.error(房态加载失败, err)); } setInterval(loadRoomStatus, 30000); loadRoomStatus();逻辑说明Number(room.status)强制转数字因为 JSON 里如果后端用字符串拼可能返回0用对象取值会拿到undefined。参数上30000 毫秒是经验值太短数据库压力大太长前台看到的状态滞后。status-前缀的 class 交给 CSS 上色空闲绿、在住红、待打扫黄一眼能分辨。4. 并发预订和夜审两个最容易翻车的地方4.1 同一间房被两个订单同时锁定的排查现象两个前台同时给同一间房办入住系统都提示成功房间出现两条在住订单。原因校验和写入之间没有锁或者用了 MyISAM 引擎不支持事务。解决room和order表必须用 InnoDB校验时SELECT ... FOR UPDATE并且把校验和写入放在同一个事务里。如果已经出现脏数据用下面 SQL 找出同一房间时间重叠的在住订单。-- 排查同一房间存在多条在住订单 SELECT room_id, COUNT(*) AS cnt FROM order WHERE status 1 GROUP BY room_id HAVING cnt 1;逻辑说明status1是在住正常情况下一间房最多一条。HAVING cnt 1筛出异常。参数上查出后要人工核对哪条是真实入住把另一条置为取消并修正房态不能直接删订单是财务凭证。4.2 夜审为什么不能放在凌晨自动跑现象系统设了凌晨 2 点自动夜审把当天未退的订单全部续一天结果有客人凌晨 1 点退房被多收一天钱投诉。原因夜审的语义是“把营业日推进到第二天”不是“给所有在住订单加一天”退房操作和夜审有竞争。解决夜审前先锁订单表只处理status1且checkout_time IS NULL的订单并且夜审时间设在凌晨 4 点到 5 点之间避开退房高峰。更稳的做法是夜审只生成一条营业日记录金额按实际退房时间算不预加。-- 夜审仅对仍在住且未退的订单延长记录营业日 START TRANSACTION; INSERT INTO business_day(day_date, created_at) VALUES(CURDATE(), NOW()); UPDATE order SET checkout_time DATE_ADD(checkout_time, INTERVAL 1 DAY) WHERE status 1 AND checkout_time IS NOT NULL AND checkout_time NOW(); COMMIT;逻辑说明checkout_time NOW()只处理已经过了退房时间还没退的正常退房的不会被误伤。参数上business_day表用来对账每天一条。夜审失败要能回滚所以必须包事务。4.3 MySQL 连接和字符集的常见配置错误现象JSP 页面插入中文客人姓名变成???或者报Unknown character set。原因JDBC URL 没指定characterEncoding或者数据库、表、连接三处字符集不一致。解决JDBC URL 加?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai建库时DEFAULT CHARSETutf8mb4。另外 MySQL 8.0 默认驱动类变成com.mysql.cj.jdbc.Driver老代码写com.mysql.jdbc.Driver会警告虽然还能跑但建议改掉。# 建库时一次性定好字符集 CREATE DATABASE hotel DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;逻辑说明utf8mb4 比 utf8 多支持 emoji 和部分生僻字酒店客人姓名里偶尔有。参数上serverTimezone不设会报时区错误设成Asia/Shanghai和数据库服务器一致。5. 避坑与排查五条血泪经验现象一房态看板显示空闲点进去却提示已入住。原因看板数据是 30 秒前的缓存期间有人办了入住。解决入住提交前必须再查一次数据库不能只信前端传来的状态这就是 3.1 里FOR UPDATE校验的意义。现象二退房后房间一直显示“待打扫”保洁做完没人改状态。原因系统没给保洁提供操作入口或者入口藏太深。解决加一个简单的保洁页面扫房号或点按钮把status从 2 改回 0并记录打扫时间。别指望前台顺手改职责要分开。现象三订单金额算出来是负数或零。原因checkin_time存成了字符串DATEDIFF返回 NULL乘价格后变 NULL 或 0。解决数据库字段用 DATETIME插入用NOW()或标准格式yyyy-MM-dd HH:mm:ss别用2025/3/5这种斜杠格式。现象四JSP 页面加载后数据不刷新要手动 F5。原因浏览器缓存了 GET 请求。解决接口加时间戳参数?tDate.now()或者响应头设Cache-Control: no-cache。这个在调试阶段特别明显上线后反而容易被忽略。现象五MySQL 报Too many connections。原因每次请求都新建连接且没关或者连接池配太小。解决用连接池如 Druid 或 HikariCPmaxActive设 20 到 50 之间并且确保finally里关闭。JSP 里直接DriverManager.getConnection是新手最常见的翻车点。6. 把房态查询做成可复用的存储过程与索引优化系统跑起来之后最慢的查询往往是“查某天有哪些空房”。如果每次都用 2.2 里的子查询逐间房判断100 间房就是 100 次查询前台点一下要等好几秒。进阶做法是写一个存储过程一次返回指定日期区间的可用房间列表并在order表的(room_id, checkin_time, checkout_time)上建联合索引。-- 查询指定日期区间内所有可用房间 DELIMITER // CREATE PROCEDURE GetAvailableRooms( IN p_checkin DATETIME, IN p_checkout DATETIME ) BEGIN SELECT r.id, r.room_no, t.type_name, t.price FROM room r JOIN room_type t ON r.type_id t.id WHERE r.status ! 3 AND r.id NOT IN ( SELECT o.room_id FROM order o WHERE o.status IN (0, 1) AND o.checkin_time p_checkout AND (o.checkout_time IS NULL OR o.checkout_time p_checkin) ); END // DELIMITER ; -- 联合索引覆盖房态判断的三个字段 CREATE INDEX idx_order_room_time ON order(room_id, checkin_time, checkout_time);逻辑说明存储过程把判断逻辑收进数据库减少网络往返。NOT IN子查询在房间数不多时够用如果房间上千改成LEFT JOIN ... IS NULL更快。索引顺序room_id在前因为子查询先按房间过滤再比时间。参数上p_checkin和p_checkout由 Java 端传入格式统一yyyy-MM-dd HH:mm:ss。验证方法开两个数据库客户端同时执行GetAvailableRooms(2025-03-05 14:00:00,2025-03-08 12:00:00)再同时用 3.1 的入住逻辑抢同一间房观察是否只有一个成功。如果两个都成功说明索引没生效或事务隔离级别不对检查SELECT transaction_isolation是否为REPEATABLE-READ。我自己的习惯是每加一个涉及房态的接口先在测试库把order表灌 500 条跨月数据再用EXPLAIN看执行计划确认走了idx_order_room_time才提交代码。这个习惯帮我省过至少三次上线后的性能投诉。酒店系统不怕功能少就怕状态乱把房态和订单的时间区间锁死剩下的都是体力活。希望帮到你。本文还有配套的精品资源点击获取 基于JSP的酒店住宿管理系统设计与实现：房态管理与订单事务处理
简介这份资源是《酒店住宿管理系统的设计与实现》毕业设计文档面向计算机相关专业学生及需要完成管理信息系统课程设计的学习者帮助解决从需求分析到系统测试全流程的写作与开发参考问题。压缩包内共1个doc文件约1.61MB完整呈现论文结构。文档围绕B/S架构展开涵盖HTML、JavaScript、JSP与MySQL等关键技术并系统梳理了客房管理、财务管理、订单管理、管理员管理四大功能模块的设计思路同时包含架构概述、开发环境说明、可行性分析、界面与代码实现及测试用例等内容。目前已有109人学习适合需要参考选题背景、技术选型、数据库设计及论文框架的读者可据此快速理清毕业设计的写作脉络与功能模块划分也可作为同类管理信息系统开发的对照模板。1. 酒店住宿管理系统的设计与实现从一张入住登记表到能跑通的 JSP 工程酒店前台最怕的不是满房而是凌晨两点一位客人拿着房卡说“我房间已经有人住了”。这种事故九成不是服务员粗心而是住宿管理系统在房态同步、订单状态流转上留了缝。所谓酒店住宿管理系统本质是把“预订—入住—换房—退房—夜审”这条链路用数据库事务锁死让每一间房在任意时刻只有一个确定状态。它适合两类人一是要做课程设计或毕业设计的学生需要一套能演示、能答辩、代码量可控的方案二是中小型酒店或民宿的自建需求预算有限、不想上重型 PMS。常见技术选型是 JSP Servlet MySQL前端用 HTML/JavaScript 渲染这套组合虽然老但部署简单、资料多、排错直观对单店几十到上百间房的体量完全够用。下面按“先立住数据模型再跑通入住退房最后处理并发和夜审”的顺序讲透。2. 先把房态和订单的数据模型定死三张表撑起整个系统2.1 为什么房间、房型、订单必须拆成三张表很多人一上来就画一张room表把房号、价格、入住人、入住时间全塞进去结果换房时要么丢历史要么把旧记录覆盖掉。正确做法是拆成三张核心表room_type房型管价格和床位描述、room物理房间管房号和当前状态、order订单管客人、时间、金额。房态不存“空闲/占用”这种会变的字段到room里当唯一依据而是由订单的checkin_time和checkout_time反推room只保留一个status做快速筛选。-- 房型表价格挂在这里不挂房间 CREATE TABLE room_type ( id INT PRIMARY KEY AUTO_INCREMENT, type_name VARCHAR(32) NOT NULL, -- 大床房/标间 price DECIMAL(10,2) NOT NULL, -- 门市价 bed_count TINYINT DEFAULT 1 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 房间表只存物理属性和当前状态 CREATE TABLE room ( id INT PRIMARY KEY AUTO_INCREMENT, room_no VARCHAR(8) NOT NULL UNIQUE, -- 如 8801 type_id INT NOT NULL, status TINYINT DEFAULT 0, -- 0空闲 1已入住 2待打扫 3维修 FOREIGN KEY (type_id) REFERENCES room_type(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单表时间区间是房态的真正来源 CREATE TABLE order ( id INT PRIMARY KEY AUTO_INCREMENT, room_id INT NOT NULL, guest_name VARCHAR(32) NOT NULL, phone VARCHAR(20), checkin_time DATETIME NOT NULL, checkout_time DATETIME, status TINYINT DEFAULT 0, -- 0预订 1在住 2已退 3取消 amount DECIMAL(10,2), FOREIGN KEY (room_id) REFERENCES room(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;逻辑说明room.status是给前台看板用的冗余字段真正判断某天某房是否可订要查order表里有没有时间区间重叠且状态为 0 或 1 的记录。参数上status用 TINYINT 而不是字符串是为了索引效率checkout_time允许为空表示尚未退房。字符集统一 utf8mb4避免客人姓名里的生僻字或 emoji 存进去变问号。2.2 用 SQL 判断房间在指定日期是否可订前台点“预订”时系统必须回答一个问题这间房从 3 月 5 日到 3 月 8 日有没有冲突。标准写法是区间重叠判断不要用BETWEEN硬套因为退房当天通常可以再入住。-- 查询 room_id5 在 [2025-03-05, 2025-03-08) 是否可订 SELECT COUNT(*) AS conflict FROM order WHERE room_id 5 AND status IN (0, 1) AND checkin_time 2025-03-08 14:00:00 AND (checkout_time IS NULL OR checkout_time 2025-03-05 12:00:00);逻辑说明checkin_time 新退房时间且旧退房时间 新入住时间两个条件同时成立才算重叠。checkout_time IS NULL表示客人还在住必须算冲突。参数上入住时间一般取当天 14:00退房取次日 12:00这是行业惯例写死在配置里比让前台手填更稳。conflict返回 0 才允许下单返回大于 0 就提示“该房型已满建议换房”。提示order是 MySQL 关键字建表和查询时务必用反引号包起来否则在部分版本直接报语法错误这个坑我见过太多次。3. 用 JSP Servlet 跑通入住和退房的最小闭环3.1 入住登记的 Servlet 与事务边界入住不是简单 INSERT 一条订单它要同时改room.status和写订单两个操作必须在一个事务里。JSP 只负责展示表单业务逻辑放 Servlet这是 MVC 的基本纪律也是答辩时老师最爱问的点。// CheckinServlet.java 核心片段 protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { int roomId Integer.parseInt(req.getParameter(roomId)); String guestName req.getParameter(guestName); String phone req.getParameter(phone); Connection conn null; try { conn DBUtil.getConnection(); conn.setAutoCommit(false); // 开启事务 // 1. 再次校验房态防止并发重复入住 PreparedStatement check conn.prepareStatement( SELECT status FROM room WHERE id? FOR UPDATE); check.setInt(1, roomId); ResultSet rs check.executeQuery(); if (!rs.next() || rs.getInt(status) ! 0) { conn.rollback(); resp.getWriter().write({\code\:1,\msg\:\房间不可入住\}); return; } // 2. 写订单 PreparedStatement ins conn.prepareStatement( INSERT INTO order(room_id,guest_name,phone,checkin_time,status) VALUES(?,?,?,NOW(),1)); ins.setInt(1, roomId); ins.setString(2, guestName); ins.setString(3, phone); ins.executeUpdate(); // 3. 改房态 PreparedStatement upd conn.prepareStatement( UPDATE room SET status1 WHERE id?); upd.setInt(1, roomId); upd.executeUpdate(); conn.commit(); resp.getWriter().write({\code\:0,\msg\:\入住成功\}); } catch (Exception e) { if (conn ! null) try { conn.rollback(); } catch (SQLException ex) {} throw new ServletException(e); } finally { if (conn ! null) try { conn.setAutoCommit(true); conn.close(); } catch (SQLException ex) {} } }逻辑说明SELECT ... FOR UPDATE是关键它给这一行加排他锁两个前台同时点同一间房只有一个能拿到锁并继续另一个会阻塞到事务结束再读到status1从而被拒绝。参数上checkin_time用NOW()由数据库生成避免应用服务器和数据库时钟不一致。返回 JSON 而不是跳转页面是为了配合前端 JavaScript 做无刷新提示。3.2 退房结算与房态置为待打扫退房要算钱还要把房间状态改成“待打扫”不能直接置空闲否则保洁没做就被下一个客人订走。金额按实际住店天数乘房型价格天数用DATEDIFF算不足一天按一天。-- 退房更新订单和房态金额按天计算 UPDATE order o JOIN room r ON o.room_id r.id JOIN room_type t ON r.type_id t.id SET o.checkout_time NOW(), o.status 2, o.amount GREATEST(DATEDIFF(NOW(), o.checkin_time), 1) * t.price, r.status 2 WHERE o.id ? AND o.status 1;逻辑说明GREATEST(..., 1)保证当天入住当天退也收一天钱。o.status 1作为条件防止重复退房。参数上?是订单 ID由前端从在住列表传入。执行后受影响行数为 0说明订单状态不对或已被退要提示前台刷新。3.3 前端房态看板用 JavaScript 定时刷新前台看板要实时但没必要上 WebSocket用setInterval每 30 秒拉一次接口就够。JSP 页面里嵌 JavaScript注意数据类型判断接口返回的status是数字别用和字符串混比。// 房态看板轮询30 秒一次 function loadRoomStatus() { fetch(RoomStatusServlet) .then(res res.json()) .then(data { const grid document.getElementById(roomGrid); grid.innerHTML ; data.forEach(room { const div document.createElement(div); // 严格判断类型避免 0 0 的隐式转换坑 const statusMap {0: 空闲, 1: 在住, 2: 待打扫, 3: 维修}; div.className room-cell status- Number(room.status); div.textContent room.roomNo statusMap[Number(room.status)]; grid.appendChild(div); }); }) .catch(err console.error(房态加载失败, err)); } setInterval(loadRoomStatus, 30000); loadRoomStatus();逻辑说明Number(room.status)强制转数字因为 JSON 里如果后端用字符串拼可能返回0用对象取值会拿到undefined。参数上30000 毫秒是经验值太短数据库压力大太长前台看到的状态滞后。status-前缀的 class 交给 CSS 上色空闲绿、在住红、待打扫黄一眼能分辨。4. 并发预订和夜审两个最容易翻车的地方4.1 同一间房被两个订单同时锁定的排查现象两个前台同时给同一间房办入住系统都提示成功房间出现两条在住订单。原因校验和写入之间没有锁或者用了 MyISAM 引擎不支持事务。解决room和order表必须用 InnoDB校验时SELECT ... FOR UPDATE并且把校验和写入放在同一个事务里。如果已经出现脏数据用下面 SQL 找出同一房间时间重叠的在住订单。-- 排查同一房间存在多条在住订单 SELECT room_id, COUNT(*) AS cnt FROM order WHERE status 1 GROUP BY room_id HAVING cnt 1;逻辑说明status1是在住正常情况下一间房最多一条。HAVING cnt 1筛出异常。参数上查出后要人工核对哪条是真实入住把另一条置为取消并修正房态不能直接删订单是财务凭证。4.2 夜审为什么不能放在凌晨自动跑现象系统设了凌晨 2 点自动夜审把当天未退的订单全部续一天结果有客人凌晨 1 点退房被多收一天钱投诉。原因夜审的语义是“把营业日推进到第二天”不是“给所有在住订单加一天”退房操作和夜审有竞争。解决夜审前先锁订单表只处理status1且checkout_time IS NULL的订单并且夜审时间设在凌晨 4 点到 5 点之间避开退房高峰。更稳的做法是夜审只生成一条营业日记录金额按实际退房时间算不预加。-- 夜审仅对仍在住且未退的订单延长记录营业日 START TRANSACTION; INSERT INTO business_day(day_date, created_at) VALUES(CURDATE(), NOW()); UPDATE order SET checkout_time DATE_ADD(checkout_time, INTERVAL 1 DAY) WHERE status 1 AND checkout_time IS NOT NULL AND checkout_time NOW(); COMMIT;逻辑说明checkout_time NOW()只处理已经过了退房时间还没退的正常退房的不会被误伤。参数上business_day表用来对账每天一条。夜审失败要能回滚所以必须包事务。4.3 MySQL 连接和字符集的常见配置错误现象JSP 页面插入中文客人姓名变成???或者报Unknown character set。原因JDBC URL 没指定characterEncoding或者数据库、表、连接三处字符集不一致。解决JDBC URL 加?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai建库时DEFAULT CHARSETutf8mb4。另外 MySQL 8.0 默认驱动类变成com.mysql.cj.jdbc.Driver老代码写com.mysql.jdbc.Driver会警告虽然还能跑但建议改掉。# 建库时一次性定好字符集 CREATE DATABASE hotel DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;逻辑说明utf8mb4 比 utf8 多支持 emoji 和部分生僻字酒店客人姓名里偶尔有。参数上serverTimezone不设会报时区错误设成Asia/Shanghai和数据库服务器一致。5. 避坑与排查五条血泪经验现象一房态看板显示空闲点进去却提示已入住。原因看板数据是 30 秒前的缓存期间有人办了入住。解决入住提交前必须再查一次数据库不能只信前端传来的状态这就是 3.1 里FOR UPDATE校验的意义。现象二退房后房间一直显示“待打扫”保洁做完没人改状态。原因系统没给保洁提供操作入口或者入口藏太深。解决加一个简单的保洁页面扫房号或点按钮把status从 2 改回 0并记录打扫时间。别指望前台顺手改职责要分开。现象三订单金额算出来是负数或零。原因checkin_time存成了字符串DATEDIFF返回 NULL乘价格后变 NULL 或 0。解决数据库字段用 DATETIME插入用NOW()或标准格式yyyy-MM-dd HH:mm:ss别用2025/3/5这种斜杠格式。现象四JSP 页面加载后数据不刷新要手动 F5。原因浏览器缓存了 GET 请求。解决接口加时间戳参数?tDate.now()或者响应头设Cache-Control: no-cache。这个在调试阶段特别明显上线后反而容易被忽略。现象五MySQL 报Too many connections。原因每次请求都新建连接且没关或者连接池配太小。解决用连接池如 Druid 或 HikariCPmaxActive设 20 到 50 之间并且确保finally里关闭。JSP 里直接DriverManager.getConnection是新手最常见的翻车点。6. 把房态查询做成可复用的存储过程与索引优化系统跑起来之后最慢的查询往往是“查某天有哪些空房”。如果每次都用 2.2 里的子查询逐间房判断100 间房就是 100 次查询前台点一下要等好几秒。进阶做法是写一个存储过程一次返回指定日期区间的可用房间列表并在order表的(room_id, checkin_time, checkout_time)上建联合索引。-- 查询指定日期区间内所有可用房间 DELIMITER // CREATE PROCEDURE GetAvailableRooms( IN p_checkin DATETIME, IN p_checkout DATETIME ) BEGIN SELECT r.id, r.room_no, t.type_name, t.price FROM room r JOIN room_type t ON r.type_id t.id WHERE r.status ! 3 AND r.id NOT IN ( SELECT o.room_id FROM order o WHERE o.status IN (0, 1) AND o.checkin_time p_checkout AND (o.checkout_time IS NULL OR o.checkout_time p_checkin) ); END // DELIMITER ; -- 联合索引覆盖房态判断的三个字段 CREATE INDEX idx_order_room_time ON order(room_id, checkin_time, checkout_time);逻辑说明存储过程把判断逻辑收进数据库减少网络往返。NOT IN子查询在房间数不多时够用如果房间上千改成LEFT JOIN ... IS NULL更快。索引顺序room_id在前因为子查询先按房间过滤再比时间。参数上p_checkin和p_checkout由 Java 端传入格式统一yyyy-MM-dd HH:mm:ss。验证方法开两个数据库客户端同时执行GetAvailableRooms(2025-03-05 14:00:00,2025-03-08 12:00:00)再同时用 3.1 的入住逻辑抢同一间房观察是否只有一个成功。如果两个都成功说明索引没生效或事务隔离级别不对检查SELECT transaction_isolation是否为REPEATABLE-READ。我自己的习惯是每加一个涉及房态的接口先在测试库把order表灌 500 条跨月数据再用EXPLAIN看执行计划确认走了idx_order_room_time才提交代码。这个习惯帮我省过至少三次上线后的性能投诉。酒店系统不怕功能少就怕状态乱把房态和订单的时间区间锁死剩下的都是体力活。希望帮到你。本文还有配套的精品资源点击获取