简介：这份文档是电影院售票管理系统课程设计的完整实验报告，面向数据库、软件工程相关课程的学生与需要参考系统设计文档的开发者。内容围绕售票业务的需求分析、数据字典、系统结构图、数据流图展开，并完整覆盖概念模型E-R图、逻辑模型、物理模型及存储过程与触发器设计，同时对UML建模工具、Java/Python实现框架等软件工程知识点作了归纳。资源包共1个文件，为doc格式文档，体积约2.8MB，适合用于课程设计参考、实验报告撰写以及数据库系统设计的案例学习。已有182人学习下载，文档内容结构清晰、图表与文字配合完整，可帮助读者快速梳理从需求到实现的整体流程，直接套用其中的设计思路与数据库模型。
1. 电影院售票管理系统：先定业务边界，再谈技术选型
电影院售票管理系统，说到底是把“影片排片、选座锁座、订单支付、入场核验、退票结账”这条业务链路用软件重新做一遍。很多第一次做这个标题的人，拿到需求就急着画页面，等联调才发现抢座超卖、支付回调后不出票、日终对账不平才是真正卡住上线的问题。一套能落地的售票系统的价值在于：观众看到哪些场次剩余多少座、哪些座位可选，售票员两三秒完成出票，运营者拿到一张经得起核对的日报表。它适合正在做课程设计的同学，也适合给中小型影厅搭自营售票后台的从业者。动手写代码前把业务边界梳理清楚，后面能少走很多弯路。
2. 数据建模：电影、场次、座位三张表的边界怎么划
开工第一件事不是做登录注册，而是把库表建稳。电影院售票管理系统的表结构，网上能找到的示例很多，但不少把座位、场次、订单揉成一张表，一上并发就崩。我的习惯是先拆出六张核心表：影片、影厅、座位、放映计划、订单、电影票。它们之间的关系是：电影被安排进影厅成为场次；座位归属于影厅；场次和座位组合起来才是可售卖的商品；卖出后产生订单和电影票。
2.1 为什么拆成六张表而不是三张
有人会说，把 movie 字段直接加进 schedule，把座位存成 hall 表里的一个 JSON 字符串，不也能跑？短期确实跑得动，但越往后越别扭。排片页需要展示“近期热映”的影片名和时长，如果影片信息挤在 schedule 上，每加一个场次就要复制一遍片名和时长，哪天改片名要用 UPDATE 扫一遍所有场次；座位如果存在 hall 表的字符串字段里，影院改造加一排座位就没法增量处理，只能整厅重置。
影厅和座位是物理资源，受装修和硬件影响，一次建好长期不变；场次是销售资源，同一个影厅一天放六部片就有六个场次，场次之间互不影响，各自维护自己的座位占用情况。订单和票则是销售结果，属于流水数据，要尽可能多地冗余业务发生时的现场信息，方便后续对账和打印。把物理资源、销售资源、流水数据分开，是这个系统建模的核心原则。
如果只拆三张表，通常是把 hall 和 seat 合并、把 movie 和 schedule 合并，这样写页面时确实少两次 join，但等你要做“某个厅未来七天的排片列表”或者“某部电影在哪些厅哪些时段上映”的时候，就得在一个表里做各种带条件的聚合，索引很难设计。拆成六张表以后，每一张表的职责都很单一，索引也容易命中。
2.2 建表 SQL 与关键字段说明
下面是我在项目里第一版就能直接跑起来的基础 DDL，去掉了权限和审计字段，只留核心骨架。先建影片表：
CREATE TABLE movie ( movie_id INT AUTO_INCREMENT PRIMARY KEY, movie_name VARCHAR(64) NOT NULL COMMENT '片名', duration_min SMALLINT NOT NULL COMMENT '时长（分钟）', language VARCHAR(20) DEFAULT '国语' COMMENT '语种', launch_date DATE NULL COMMENT '上映日期', status TINYINT DEFAULT 1 COMMENT '1排片中 0已下线', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_status_launch (status, launch_date) ) COMMENT='影片基础信息';duration_min 必须单独存。它不只展示用，还决定 schedule 的 end_time 冗余值，排片页也是靠它算散场时间。launch_date 用于“即将上映”和“正在热映”的分组，status 用来下架老片，下架后不再出现在新场次可选列表里。
然后是影厅和座位两张物理表：
CREATE TABLE hall ( hall_id INT AUTO_INCREMENT PRIMARY KEY, hall_name VARCHAR(30) NOT NULL COMMENT '厅名，如1号厅', row_count SMALLINT NOT NULL COMMENT '总排数', seat_per_row SMALLINT NOT NULL COMMENT '每排座位数', layout_desc VARCHAR(255) NULL COMMENT '特殊区域描述，如情侣座区域', is_active TINYINT DEFAULT 1 COMMENT '1营业中 0停用' ) COMMENT='放映厅'; CREATE TABLE seat ( seat_id INT AUTO_INCREMENT PRIMARY KEY, hall_id INT NOT NULL COMMENT '所属影厅', row_no SMALLINT NOT NULL COMMENT '排号', col_no SMALLINT NOT NULL COMMENT '列号', seat_type TINYINT DEFAULT 0 COMMENT '0普通 1双人 2无障碍', deleted TINYINT DEFAULT 0 COMMENT '0正常 1停用', UNIQUE KEY uk_hall_seat (hall_id, row_no, col_no), KEY idx_hall_deleted (hall_id, deleted) ) COMMENT='座位表';seat 表最关键的是一把联合唯一索引 uk_hall_seat。它在建表层面就杜绝了同一个厅里重复生成同排同列座位的情况，后续批量生成座位可以放心跑 INSERT IGNORE。deleted 字段用于停用某个坏掉的座椅，而不是物理删除行，否则历史订单和座位快照会失去对应关系。
接着是放映计划表 schedule，它是这个系统的销售单元：
CREATE TABLE schedule ( schedule_id INT AUTO_INCREMENT PRIMARY KEY, movie_id INT NOT NULL COMMENT '影片ID', hall_id INT NOT NULL COMMENT '影厅ID', show_time DATETIME NOT NULL COMMENT '开场时间', end_time DATETIME NOT NULL COMMENT '冗余散场时间=开场+时长', base_price DECIMAL(8,2) NOT NULL COMMENT '基础票价', seat_status JSON DEFAULT NULL COMMENT '座位状态快照，1可选 0占用', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_movie_show (movie_id, show_time), KEY idx_hall_show (hall_id, show_time), CONSTRAINT fk_schedule_movie FOREIGN KEY (movie_id) REFERENCES movie (movie_id), CONSTRAINT fk_schedule_hall FOREIGN KEY (hall_id) REFERENCES hall (hall_id) ) COMMENT='放映计划';end_time 是冗余字段，选场次列表按“即将开场”排序时，直接拿 end_time 过滤即可，不用每行临时算一次。base_price 是基础票价，实际订单金额可能会叠加会员折扣或活动价，所以它只作为创建订单时的默认值。seat_status 是 JSON 快照，选座页读取它就能一次画出 200 个座位的占用情况，不用 join 订单和票表。
最后是订单和电影票两张流水表：
CREATE TABLE orders ( order_id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT '业务单号', schedule_id INT NOT NULL, show_time DATETIME NOT NULL COMMENT '冗余场次时间', movie_name VARCHAR(64) NOT NULL COMMENT '冗余影片名', hall_name VARCHAR(30) NOT NULL COMMENT '冗余厅名', seat_summary VARCHAR(255) NOT NULL COMMENT '座位快照，如5排6座,5排7座', total_amount DECIMAL(10,2) NOT NULL COMMENT '订单总金额', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待支付 1已支付 2已出票 3已退票 4已过期', expire_time DATETIME NOT NULL COMMENT '支付截止时间', pay_time DATETIME NULL COMMENT '支付完成时间', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_schedule_status (schedule_id, status), KEY idx_created (created_at) ) COMMENT='订单主表'; CREATE TABLE ticket ( ticket_id INT AUTO_INCREMENT PRIMARY KEY, order_id BIGINT NOT NULL COMMENT '所属订单', order_no VARCHAR(32) NOT NULL COMMENT '冗余订单号', schedule_id INT NOT NULL, seat_id INT NOT NULL COMMENT '座位ID', seat_label VARCHAR(16) NOT NULL COMMENT '排号座号快照', verify_code VARCHAR(8) NOT NULL COMMENT '入场核验码', status TINYINT DEFAULT 0 COMMENT '0未入场 1已入场', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_ticket_schedule_seat (schedule_id, seat_id), KEY idx_order (order_id) ) COMMENT='电影票';订单表把 show_time、movie_name、hall_name、seat_summary 这些本可以 join 出来的字段都冗余了一份。原因是流水表要保留下单那一刻的事实，幕布下半个月修改了片名，历史订单也不能跟着变。ticket 表上那把联合唯一索引 uk_ticket_schedule_seat 是整个系统防超卖的兜底，同一个场次同一个座位，数据库层面只能存在一条有效记录。
2.3 场次与座位状态缓存：JSON 字段的取舍
打开选座页时，如果每次都去查 schedule、join hall、再 join ticket 才能算出哪些座位可售，一个 200 座的影厅在大流量下会反复执行多表查询。常见做法是在 schedule.seat_status 里放一份座位状态快照，每个场次一行 JSON，值用 1 表示可选、0 表示已占用。页面一次查询拿到全部座位状态，体验和数据库压力都友好。
下单成功时，在同一事务里执行 INSERT ticket 和 UPDATE schedule.seat_status 两条语句，保证快速生成的快照和实际票数据一致。这样做的代价是 JSON 字段无法像普通行那样做细粒度索引，但单场次座位量级只有几百，全量读写完全扛得住。需要强调的是，seat_status 只是读缓存，真正的凭证永远在 ticket 表；如果缓存被写坏，可以扫描 ticket 表重建，它不作为唯一的业务依据。
3. 售票核心链路：从锁座到出票的状态机
库表理顺之后，就该面对整个系统里最容易出错的一段链路：订单状态机。在这个系统里，订单不是简单的一条数据，它要在待支付、已支付、已出票、已退票、已过期之间流转。状态机画错，就会出现用户付了钱座位又被抢、退完票座位仍是灰色占着这样的线上事故。这一章把锁座方案、代码骨架和超时参数一次说透。
3.1 锁座方案选型：数据库行锁与 Redis 过期键
“同一场次、同一座位，只能被一个人锁住”这件事，有两条常见实现路径。第一条是纯数据库方案：在 ticket 表先插入一条待支付记录，靠唯一索引 uk_ticket_schedule_seat 拦住重复插入，谁先插入成功谁就锁定座位。第二条是 Redis 加数据库组合方案：先用 Redis SETNX 抢一个带过期时间的锁，抢到后再写订单和 ticket，Redis 负责挡住大部分并发冲突。
纯数据库方案简单且绝对一致，但致命缺点是票表会堆积大量待支付记录，状态要等支付回调才能转正；如果用户放弃支付，还得定时任务清扫。Redis 加数据库方案把“快速抢座”和“最终落库”分开，抢座阶段毫秒级返回，数据库只处理真正进入下单流程的请求。我的建议是，日售票量在五千张以下直接走纯数据库方案，完全够用；超过这个量级再上 Redis，避免为了并发而并发，给自己增加双写一致性的维护成本。下面的代码骨架按 Redis 加数据库方案写，这是我在线上项目里用得最多的组合。
3.2 下单出票的时序逻辑与代码骨架
下单流程按顺序分五步：校验座位可售、抢占 Redis 锁、数据库事务写入订单和票、更新场次座位快照、释放锁。下面这段代码展示的是最核心的锁座和订单创建逻辑：
from datetime import datetime, timedelta import random, string def create_order(db, redis, schedule_id, seat_ids, account_id): # 锁 key 用场次加座位集合拼接，保证同一批座位只有一个并发请求能拿到 seat_part = ",".join(sorted([str(s) for s in seat_ids])) lock_key = f"lock:schedule:{schedule_id}:seats:{seat_part}" lock_ok = redis.set(lock_key, account_id, nx=True, ex=900) if not lock_ok: raise BizError(409, "座位锁定中，请重新选座") try: with db.transaction(): # 先查已售记录，FOR UPDATE 锁住这一批座位的判定行 rows = db.query( "SELECT seat_id FROM ticket " "WHERE schedule_id=%s AND seat_id IN (%s) FOR UPDATE", (schedule_id, ",".join([str(s) for s in seat_ids])), ) if rows: raise BizError(409, "座位已被售出") order_no = generate_order_no() expire_time = datetime.now() + timedelta(minutes=15) db.execute( "INSERT INTO orders (order_no, schedule_id, show_time, movie_name, " "hall_name, seat_summary, total_amount, status, expire_time) " "VALUES (%s, %s, %s, %s, %s, %s, %s, 0, %s)", (order_no, schedule_id, schedule.show_time, schedule.movie_name, schedule.hall_name, seat_summary, schedule.base_price * len(seat_ids), expire_time), ) for seat_id in seat_ids: db.execute( "INSERT INTO ticket (order_id, order_no, schedule_id, seat_id, " "seat_label, verify_code) VALUES (%s, %s, %s, %s, %s, %s)", (order_id, order_no, schedule_id, seat_id, label_of(seat_id), random_code(6)), ) return {"order_no": order_no} except BaseException: redis.delete(lock_key) raise这段代码里有三个参数值得单独说。第一个是 Redis 锁的 ex=900，表示锁住 900 秒，也就是 15 分钟，和订单表的 expire_time 保持一致；用户有 15 分钟完成支付，超时后定时任务会把订单置为过期并释放座位。第二个是 ticket 表唯一索引 uk_ticket_schedule_seat，它才是防超卖的最后防线，Redis 锁只是把并发冲突挡在前面，即使 Redis 出问题，数据库唯一索引也不会允许同一座位插入两次。第三个是 verify_code，我用大写字母加数字混成的六位随机码，入场检票时输入这个码即可。
注意代码里 Redis 锁的 key 是“场次加座位集合”的拼接结果，不是每个座位单独一个锁。这样设计的好处是，用户一次选四个座位时，四个座位要么全部锁定，要么全部放弃，不会出现只锁住一半的中间态。
3.3 超时、退款与释放回写的参数设置
订单创建完成后，定时任务要负责清扫过期订单。我的习惯是每 60 秒扫一次，SQL 条件是 status=0 且 expire_time < NOW()，把订单状态批量改成 4（已过期），同时把对应座位的 ticket 记录标记为失效，并回写 schedule.seat_status。这个动作必须和主动退票复用同一个释放函数，不要两处各写一套。否则非常容易出现在 A 处更新了订单状态、忘了回写座位快照，B 处回写了座位快照、忘了把票作废的错位问题。
释放座位的函数签名建议设计成 release_seats(schedule_id, seat_ids, reason)，reason 区分过期释放和主动退票。函数内部在一个事务里做三件事：更新订单状态、更新 ticket 状态、更新 schedule.seat_status。这样任何一步失败都会整体回滚，不会出现票已作废但座位还占着的半截状态。
退款业务还有一个参数值得做成配置项：可退票的截止时间。常见做法是开映前 30 分钟允许用户在线退票，开映后只能走现场人工处理。把这个时间阈值放在系统参数表里，而不是写死在代码里，方便运营随时调整。另外要提醒一点，如果接入了微信或支付宝支付，退票时需要同步发起原路退款，订单状态要等支付平台回调成功后再从“已退票”变成“退款完成”，这中间存在时间差，报表统计时要注意区分。
4. 电影院售票管理系统排查：五个必踩的坑
前面把链路讲通了，但真正折磨人的是各种边界情况。这五个坑是我在不同项目里反复见过、也亲手修过的，按“现象、原因、解决”的顺序整理出来，希望能帮你绕开。
4.1 座位超卖：数据库唯一索引才是底线
现象：高峰期同一个场次同一排座位，系统里出现了两张有效电影票，两个观众都拿着票进场，现场乱成一团。
原因：很多实现把“座位是否可售”的判断放在内存或 Redis 缓存里，先更新缓存再写数据库，或者先查后写。两个操作之间存在时间差，两个并发请求同时读到“可售”，同时往下走，于是超卖发生。缓存只是加速器，不是一致性的保证。
解决：把 ticket 表的 uk_ticket_schedule_seat（schedule_id + seat_id）当作防超卖的唯一底线。业务代码不要做“先 SELECT 判断再 INSERT”，而是直接 INSERT，由数据库唯一索引来决定谁能成功。插入撞了唯一索引就立刻返回“座位已被选择”。Redis 锁能把 99% 的冲突请求挡在前面，剩下 1% 的漏网之鱼由唯一索引兜住，这样两层配合才是安全方案。
4.2 支付回调后不出票：订单状态回滚惹的祸
现象：用户在微信支付里已经扣款成功，但系统订单还停留在“待支付”，座位被释放，用户到前台取不到票。
原因：支付回调处理流程中，不少实现是先更新订单状态、再插入 ticket、再更新座位快照。这三步里任何一步抛出异常，整个流程都可能被事务回滚，但支付平台那边已经扣款成功，两边状态就对不上了。更隐蔽的问题是回调可能被支付平台重试多次，如果代码没有做幂等，重复回调就可能重复触发后续动作。
解决：给订单状态迁移加一个强约束，只有 status=0 的订单才允许被回调置为 1，已经置为 1 的直接返回成功，不再重复操作。ticket 表已经存在则直接返回，不要重复插入。所有写入操作都基于 order_no 做幂等键，确保重复回调不会产生副作用。最关键的是，支付回调处理流程不要手工开启事务包住“更新状态、生成票、更新快照”这三件事，而是先更新订单状态并提交，再用可靠的异步任务去生成票和更新快照，任务失败可以重试。
4.3 幽灵座位：定时释放与座位回写不同步
现象：开场前两小时，没有新增订单，选座页上却出现一大片灰色不可选座位，用户以为满场了。
原因：定时任务把超时订单的状态改成了“已过期”，但没有调用释放座位的方法。或者释放座位的方法里只更新了 ticket 状态、忘了同步 schedule.seat_status 的 JSON 快照，导致前端读到的还是占用状态。
解决：超时释放和主动退票必须共用同一个 release_seats 方法，这个方法在同一事务里同步完成“更新订单状态、作废 ticket、回写 seat_status”三件事。另外配一条核对 SQL 定时巡检，把 schedule.seat_status 里标记为占用的座位和 ticket 表实际存在的有效记录做比对，发现不一致就报警并自动重建快照。这个巡检脚本上线前期每天跑一次，稳定之后改成每天一次即可。
4.4 退票座位不可再售：异步更新的时序问题
现象：用户退票成功，退款也显示了，但后台把这个座位从库存里释放后，选座页上仍然显示灰色，刷新也没用。
原因：退票流程里把“改订单状态”和“释放座位”拆成了两个步骤，释放座位被丢进消息队列异步执行。订单状态先更新，释放动作排队等消费。高峰期队列积压，释放动作晚了几分钟甚至更久，于是出现退票成功但座位迟迟不可选。还有一个类似的情况：释放消息被重复消费，或者消费顺序颠倒，也会导致状态错乱。
解决：退票释放座位应该和订单状态更新放在同一个数据库事务里同步完成，不要拆成异步任务。只有真正需要跨系统通知时才用消息队列，比如通知支付平台退款；而释放座位这个动作是纯本地的，直接同步执行不会有多少性能损耗。如果确实因为某些原因必须异步，那释放任务必须支持幂等重试，并且重试依据是订单状态而不是座位状态。
4.5 日报表对不上账：退款与售卖混在一起统计
现象：当天售票系统汇总显示卖出 12000 元，财务从支付平台拉出来的实收只有 10500 元，中间差了 1500 元，一查全是当天退回的票款。
原因：两个统计口径打架。售票模块统计的是“订单状态为已支付”的金额，财务统计的是“当天实际入账减退款”的金额。如果报表 SQL 里没有把退款单拎出去，也没有按支付完成时间分组，就会把跨天的订单和退款全都搅在一起。
解决：报表统计统一按 pay_time 作为业务日期，而不是 create_time。金额口径拆成三列：总支付金额、退款金额、净收入金额。退款金额只统计状态为已退票的订单，净收入等于两者之差。下面是对账用的标准 SQL：
SELECT DATE(pay_time) AS biz_date, COUNT(DISTINCT order_id) AS pay_orders, SUM(total_amount) AS gross_amount, SUM(CASE WHEN status = 3 THEN total_amount ELSE 0 END) AS refund_amount, SUM(total_amount) - SUM(CASE WHEN status = 3 THEN total_amount ELSE 0 END) AS net_amount FROM orders WHERE status IN (1, 2, 3) AND pay_time >= %s AND pay_time < %s GROUP BY DATE(pay_time);执行这条 SQL 得到的结果，net_amount 应该和支付平台账单的当天净收入一致。如果还有差异，优先检查有没有支付回调还没完成的中间态订单，以及是否有线下手工改单的数据没进入报表。这个核对脚本要放在每天日结任务里自动跑，不平就要发报警。
5. 用数据核对和压测验证整套系统：上线前的最后两道关
代码写完了，联调也过了，最后我会用两类手段确认系统真正能扛事：数据一致性核对和并发压测。这两件事都做扎实了，上线才有底气。
5.1 用 SQL 做日终一致性核对
核对的核心目标是回答一个问题：已售座位数和实际座位数对得上吗？我常用下面这条 SQL，把场次的已售数和厅里的物理座位数拉出来比对：
SELECT s.schedule_id, s.movie_name, s.show_time, (SELECT COUNT(*) FROM seat se WHERE se.hall_id = s.hall_id AND se.deleted = 0) AS total_seats, (SELECT COUNT(*) FROM ticket t WHERE t.schedule_id = s.schedule_id AND t.status IN (0, 1)) AS sold_seats FROM schedule s WHERE s.show_time >= %s AND s.show_time < %s ORDER BY s.show_time;只要出现 sold_seats 大于 total_seats 的行，说明超卖发生了，立刻查那场次的订单明细。sold_seats 等于 total_seats 但选座页还能看到可选座位，说明 seat_status 快照和实际票数据不一致，需要用 ticket 表重建场次快照。这条 SQL 在高并发的压测之后跑一遍，能发现很多代码里肉眼看不见的状态错乱。
5.2 简单并发压测怎么设参数
压测不用一上来就搞复杂工具，先用命令行的 ab 或自己写一段多线程脚本即可。关键是把并发请求全部打到同一个场次同一个座位上，看最终表现：
ab -n 200 -c 50 -p seat_order.json \ -H 'Content-Type: application/json' \ -H 'Cookie: SESSION=test' \ http://127.0.0.1:8080/api/v1/orders-n 200 表示总共发出 200 个请求，-c 50 表示同时保持 50 个并发，-p 指定 POST 请求的 JSON 文件，里面写死一个 schedule_id 和两个 seat_id。判定标准有两个：第一，200 个请求里成功创建订单的数量不能超过该场次剩余可售座位数；第二，去数据库查 ticket 表，同一个 schedule_id 加 seat_id 绝对不能有两条有效记录。如果 Redis 锁生效，成功数会远小于并发数，大部分请求会收到 409 冲突提示，这是正常现象。
压测时还要关注接口响应时间。普通影院的峰值并发并不高，同一个场次同时选座的人数很难超过 50，所以把接口 P95 响应时间压在 1 秒以内就足够。如果响应时间飙到 3 秒以上，优先检查是不是每请求多次查库，或者 Redis 连接池配太小。
做完这些验证，我还有一个坚持多年的习惯：上线后连续三天抽查真实订单，把人工售票窗口的票根和系统订单逐一比对，确认打印出来的票号、场次、座位号完全一致。技术上的坑可以用代码和数据脚本填平，数据口径的坑只能靠日结习惯慢慢磨。希望帮到你。
本文还有配套的精品资源，点击获取
