电影票务系统需5张核心表：cinemas（影院）、movies（影片）、schedules（排片）、seats（座位）、orders（订单），其他均为辅助；座位按排片动态生成，用UNIQUE KEY约束防重，订单中小系统可用JSON存seat_ids，高并发需拆为order_seats表。
电影票务系统需要哪些核心表
电影票务系统本质是「资源预约+状态追踪」，不是简单的内容展示。必须先理清业务主干：影院排片、用户选座、订单生成、支付闭环、退改规则。脱离这五点设计的表结构，后期必然要返工。
关键表只有 5 张，其他都是辅助或扩展：
-
cinemas：影院基础信息（ID、名称、地址、联系电话） -
movies：影片信息（ID、片名、时长、分级、上映日期） -
schedules：排片表（ID、movie_id、cinema_id、开始时间、厅号、票价）——注意：不存结束时间，用start_time + duration动态算 -
seats：座位表（ID、schedule_id、行号row_num、列号col_num、状态status，如 'available'/'locked'/'sold'） -
orders：订单表（ID、user_id、schedule_id、seat_idsJSON 字段、总金额、状态status，如 'pending'/'paid'/'cancelled'）
别建 theaters 或 halls 单独表——厅号直接存在 schedules.hall_number 更轻量；也别为每个座位预生成百万级记录，seats 表按排片动态生成（插入新 schedule 后批量 INSERT）。
排片与座位如何关联才不锁死业务
错误做法：在 schedules 表里加一个 seat_layout TEXT 字段存 JSON 座位矩阵。后果是无法索引、无法原子更新单个座位、无法用 SQL 做“查询某场次剩余可售座位数”这类统计。
正确做法是让 seats 表成为调度核心载体，并强制外键约束：
CREATE TABLE seats (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
schedule_id BIGINT NOT NULL,
row_num TINYINT NOT NULL,
col_num TINYINT NOT NULL,
status ENUM('available', 'locked', 'sold') DEFAULT 'available',
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (schedule_id) REFERENCES schedules(id) ON DELETE CASCADE,
UNIQUE KEY uk_schedule_row_col (schedule_id, row_num, col_num)
);
这个 UNIQUE KEY uk_schedule_row_col 是关键——它确保同一场次不会重复插入同一座位，也支撑后续用 INSERT ... ON DUPLICATE KEY UPDATE 实现乐观锁选座。
常见坑：row_num 和 col_num 用 TINYINT 足够（最大 255 行/列），别用 VARCHAR 存 "A12" 这类字符串，否则无法排序、无法范围查询（比如“前10排”）。
订单表要不要拆分 seat_orders 关联表
要看并发量和查询模式。中小系统（日订单 ≤ 5000）直接在 orders 表用 JSON 存 seat_ids 数组最省事：
Destoon B2B网站管理系统是一套完善的B2B(电子商务)行业门户解决方案。系统基于PHP+MySQL开发，采用B/S架构，模板与程序分离，源码开放。模型化的开发思路，可扩展或删除任何功能；创新的缓存技术与数据库设计，可负载千万级别数据容量及访问。 系统特性1、跨平台。支持Linux/Unix/Windows服务器，支持Apache/IIS/Zeus等2、跨浏览器。基于最新Web标准构建，在
ALTER TABLE orders ADD COLUMN seat_ids JSON NOT NULL;
这样查某订单买了哪些座，一条 SELECT seat_ids FROM orders WHERE id = 123 就拿到，应用层解析即可。
但如果你需要高频执行以下操作，就必须拆表：
- 统计某部电影所有场次的上座率（需 JOIN
seat_orders→seats→schedules→movies） - 支持“部分退票”（只删关联表中几条记录，而非整个订单回滚）
- 做座位粒度的营销（如“第5排全部半价”，需 WHERE row_num = 5）
此时建 order_seats 表：
CREATE TABLE order_seats ( order_id BIGINT NOT NULL, seat_id BIGINT NOT NULL, PRIMARY KEY (order_id, seat_id), FOREIGN KEY (order_id) REFERENCES orders(id) ON DELETE CASCADE, FOREIGN KEY (seat_id) REFERENCES seats(id) ON DELETE RESTRICT );
注意 FOREIGN KEY (seat_id) 用 RESTRICT：已售出的座位不能被删，避免数据错乱。
真实场景中容易被忽略的约束细节
MySQL 默认不校验 JSON 字段格式，也不阻止你把无效时间写进 schedules.start_time。这些得靠数据库层兜底，而不是全丢给应用校验：
- 给
schedules.start_time加CHECK约束，禁止过去时间：CONSTRAINT chk_start_time CHECK (start_time >= NOW()) - 票价字段用
DECIMAL(6,2)，不用FLOAT——钱不能有浮点误差 -
orders.status必须加CHECK限定值域：CHECK (status IN ('pending', 'paid', 'cancelled', 'refunded')) - 所有外键字段（如
schedule_id）务必设NOT NULL，空值会让 JOIN 和索引失效
最后提醒一句：别在 seats 表加 user_id 字段来标记“谁锁了座”。锁是临时状态，应由应用维护锁超时（如 Redis 存锁记录），数据库只管最终落库。混用会导致锁状态和实际订单脱节，尤其在支付失败后清理逻辑极易出错。
