简介这是一个基于C#与MySQL的剧场订票管理系统完整项目面向需要进行课程设计、毕业设计或C/S架构开发的读者实现了电话订票、近三日座位预定、图形化已订座位展示、观众信息修改、退票改订以及报表输出等核心功能。资源包共116个文件约2.25MB以C#源代码30个cs、数据库脚本、项目工程文件、配置文件及可执行文件为主内含柚子影院、青鸟影院、大众影院等多套工程变体便于对照学习。目前已有1226人浏览学习适合软件工程课程设计与相关课题二次开发场景。通过完整的源码与SQL脚本读者可快速梳理剧场订票的业务流程与界面设计思路项目按软件工程设计方法组织目录模块划分清晰可直接导入运行并根据自身需求调整座位管理、报表打印等模块。1. 剧场订票管理系统到底难在哪一天几百张票背后的状态机在真正动手拆剧场订票系统之前我一度以为这类项目的难点在界面布局等把 MySQL 表结构和 C# 代码理清之后才发现核心复杂度全在“座位状态流转”这条隐线上。C# 做客户端、MySQL 做存储用剧场、场次、座位、订单、明细五张表就能支撑一个小剧场一天几百张票的售票、退票和统计技术选型并不复杂但事务边界一点都不能含糊。这份资源适合正在找课程设计题目却不想再写一遍通讯录的在校生、要快速交付桌面应用给剧场客户的开发者以及想把事务和行锁一次看明白的从业者。下面按数据库、分层代码、核心流程、踩坑和压测逐层拆解。2. 数据库设计用五张表结构和一条 UPDATE 把锁座做成卖点2.1 表结构剧场、场次、座位、订单、明细五张表怎么分剧场座位本质上是二维资源同一个剧场在不同时间段放映不同剧目同一个座位在不同场次可以重复出售因此把“演出”和“座位”混在一张表是最常见的错误设计。我采用的方案是拆成五张核心表剧场表管物理座位规模场次表管剧目和放映时间座位表按“每场次一份”复制生成订单表管购票主记录订单明细表记录每个座位在订单中的价格和状态。拆开的好处很直接剧目改期时不影响历史订单退票时不删除明细记录统计时能区分该场次“最多卖过多少座”和“当前有多少座可售”。如果只建一张宽表改一个字段就要连带更新所有历史记录数据做不到可追溯。表名核心字段作用theatertheater_id, theater_name, row_count, col_count剧场信息与座位布局尺寸scheduleschedule_id, theater_id, play_name, start_time, base_price某剧场某场演出的时间与基础票价seatseat_id, schedule_id, row_no, col_no, seat_status, lock_token, lock_time每个场次维度的座位状态ordersorder_id, schedule_id, customer_name, status, total_amount, create_time一次购票订单主表order_itemsitem_id, order_id, schedule_id, seat_id, price, status订单与座位的多对多关联明细MySQL 8.0 下的建表语句我一般写成下面这样其中几个字段特别值得注意CREATE DATABASE IF NOT EXISTS theater_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE TABLE theater ( theater_id INT PRIMARY KEY AUTO_INCREMENT, theater_name VARCHAR(50) NOT NULL, row_count SMALLINT NOT NULL DEFAULT 10, col_count SMALLINT NOT NULL DEFAULT 12 ) ENGINEInnoDB; CREATE TABLE schedule ( schedule_id INT PRIMARY KEY AUTO_INCREMENT, theater_id INT NOT NULL, play_name VARCHAR(100) NOT NULL, start_time DATETIME NOT NULL, base_price DECIMAL(10,2) NOT NULL DEFAULT 0, INDEX idx_schedule_time (start_time), CONSTRAINT fk_sched_theater FOREIGN KEY (theater_id) REFERENCES theater(theater_id) ) ENGINEInnoDB; CREATE TABLE seat ( seat_id BIGINT PRIMARY KEY AUTO_INCREMENT, schedule_id INT NOT NULL, row_no INT NOT NULL, col_no INT NOT NULL, seat_status TINYINT NOT NULL DEFAULT 0 COMMENT 0空闲 1锁定 2已售出, lock_token VARCHAR(32) NULL, lock_time DATETIME NULL, UNIQUE KEY uk_seat_schedule (schedule_id, row_no, col_no), INDEX idx_seat_status (schedule_id, seat_status) ) ENGINEInnoDB; CREATE TABLE orders ( order_id BIGINT PRIMARY KEY AUTO_INCREMENT, schedule_id INT NOT NULL, customer_name VARCHAR(50) NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1锁定 2已支付 3已取消 4已退票, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_orders_status (status) ) ENGINEInnoDB; CREATE TABLE order_items ( item_id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, schedule_id INT NOT NULL, seat_id BIGINT NOT NULL, price DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 2已退, UNIQUE KEY uk_item_seat_schedule (schedule_id, seat_id), CONSTRAINT fk_item_order FOREIGN KEY (order_id) REFERENCES orders(order_id), CONSTRAINT fk_item_seat FOREIGN KEY (seat_id) REFERENCES seat(seat_id) ) ENGINEInnoDB;几个关键点展开说一下。seat表按schedule_id维度去生成也就是说每创建一个场次就为这个场次复制一批座位记录这样同一排号在不同场次互不干扰。uk_seat_schedule联合唯一键防止同一场次重复生成相同座位。orders与order_items之所以要拆成两张表是因为一次下单可能同时选多个座位如果只有订单表一个订单只能对应一个座位客户连买两张票就得生成两条订单无法体现“一笔交易”的语义。订单明细里冗余存了schedule_id是为了报表统计时不用反复 join 订单主表。2.2 锁座的核心 SQL一条 UPDATE 把并发问题关在门外为什么要单独讲锁座座位不是普通库存。库存超卖一件顶多补发座位超卖一张观众进不了场这是事故级问题。常见的错误做法是先SELECT seat_status判断是否为空闲再UPDATE占座。这个流程在高并发下必出问题因为“查询”和“更新”之间有一个时间窗口两个售票窗口同时查到空闲又同时更新同一个座位就可能被卖两次。正确的做法是把“查”和“改”合并成一条带条件的 UPDATE由 InnoDB 的行锁保证同一时刻只有一个事务能更新该行UPDATE seat SET seat_status 1, lock_token token, lock_time NOW() WHERE schedule_id scheduleId AND seat_id seatId AND seat_status 0;执行后判断影响行数返回 1 表示锁座成功返回 0 表示座位已被其他人锁定或售出。这条 SQL 的巧妙之处在于WHERE seat_status0把条件直接写进更新语句数据库在加行锁之前就会检查这行是否满足条件不满足则跳过所以避免了“先查后改”的竞态。有的开发者会问用SELECT ... FOR UPDATE不行吗也可以但要手动处理锁、释放、异常分支多写不少代码。带条件的 UPDATE 是更简洁的乐观锁写法也是这套系统里最值得复用的模式。需要注意的是MySQL 默认隔离级别是 REPEATABLE READ在事务里执行这条 UPDATE 时它对命中行加的是行锁对条件涉及的索引区间还可能加间隙锁。因此seat_status字段上要有索引否则锁的范围可能扩大导致并发能力下降。订单创建和锁座通常在一个事务里START TRANSACTION; UPDATE seat SET seat_status 1, lock_token abc123, lock_time NOW() WHERE schedule_id 1 AND seat_id 8 AND seat_status 0; INSERT INTO orders (schedule_id, customer_name, status, total_amount) VALUES (1, customer_a, 1, 120.00); INSERT INTO order_items (order_id, schedule_id, seat_id, price, status) VALUES (LAST_INSERT_ID(), 1, 8, 120.00, 1); COMMIT;lock_token是很多人会漏掉的字段。如果只更新seat_status用户选完座但没支付系统不知道自己释放的是哪个锁只能把所有锁定座位全放掉容易误伤正常订单。带上lock_token后释放锁时可以用“先比对 token 再更新”的条件保证只有锁的持有者能释放别人动不了。2.3 锁的超时回收与索引设计锁定状态不能一直挂在那里。用户锁座十分钟不支付系统应该把座位放回空闲池。最稳的做法是定时任务扫描执行频率我一般设成每两分钟一次。SQL 长这样UPDATE seat SET seat_status 0, lock_token NULL, lock_time NULL WHERE seat_status 1 AND lock_time NOW() - INTERVAL 10 MINUTE;如果担心客户端调度任务不稳定可以在每次查询可用座位前先执行一次这个清理保证界面端看到的数据不会越积越脏。这个 SQL 的执行成本很低因为seat_status和lock_time都已经走了索引。索引方面除了建表语句里的idx_seat_status外订单报表最常按schedule_id和status过滤订单明细所以值得再建一个复合索引CREATE INDEX idx_items_schedule_status ON order_items (schedule_id, status);查询条件越贴合索引列顺序回表次数越少。这个小系统没必要做覆盖索引那套优化但该建的索引还是要建否则订单量到几千条后统计接口从毫秒级掉到秒级是很常见的。2.4 场次创建时批量生成座位一个容易漏掉的初始化步骤有了 theater 表和 schedule 表还需要为每个场次批量生成座位。这里的逻辑是新增一场演出时把剧场座位布局复制到 seat 表生成row_count * col_count条记录初始状态全部为 0。INSERT INTO seat (schedule_id, row_no, col_no, seat_status) SELECT scheduleId, r.n, c.n, 0 FROM (SELECT 1 AS n UNION SELECT 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5 UNION SELECT 6 UNION SELECT 7 UNION SELECT 8 UNION SELECT 9 UNION SELECT 10 UNION SELECT 11 UNION SELECT 12) r, (SELECT 1 AS n UNION SELECT 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5 UNION SELECT 6 UNION SELECT 7 UNION SELECT 8 UNION SELECT 9 UNION SELECT 10 UNION SELECT 11 UNION SELECT 12) c WHERE r.n (SELECT row_count FROM theater WHERE theater_id theaterId) AND c.n (SELECT col_count FROM theater WHERE theater_id theaterId);这段 SQL 用两个数字序列做笛卡尔积生成所有行列组合。实际项目中我也会用存储过程循环插入但核心逻辑相同。生成之后最好再执行一次SELECT COUNT(*) FROM seat WHERE schedule_idscheduleId校验总数防止漏掉某排。3. C# 分层实现从连接串到参数化查询的完整数据通道3.1 解决方案结构UI、BLL、DAL、Model 四层的边界怎么定拆 C# 项目时我优先按四层拆Model 放实体类DAL 放 SQL 操作BLL 放订单状态流转、超时计算等业务规则UI 层用 WinForms 只负责画界面和接收用户操作。分层的核心原则是UI 不能直接写 SQLDAL 不能包含业务判断BLL 不关心界面长什么样。解决方案里的项目我通常这样建Theater.sln ├── Theater.Model // 实体类比如 OrderInfo、SeatInfo ├── Theater.DAL // 数据访问只引用 Model 和 MySql.Data ├── Theater.BLL // 业务逻辑引用 DAL 和 Model └── Theater.WinApp // WinForms 主程序引用 BLL 和 Model依赖方向是单向的UI 引 BLL 和 ModelBLL 引 DAL 和 ModelDAL 只引 Model 和 MySql 驱动。这样做的好处是第六部分做并发压测时控制台项目可以直接引用 BLL不需要打开 WinForms 界面。很多人觉得分层代码量多但对于课程设计和交付型项目分层反而能减少返工成本——界面改动不碰业务数据库改动不碰界面两边并行不冲突。Model 类不用写得太重简单属性即可比如public class SeatInfo { public long SeatId { get; set; } public int ScheduleId { get; set; } public int RowNo { get; set; } public int ColNo { get; set; } public int SeatStatus { get; set; } public string LockToken { get; set; } }这个实体类和 seat 表字段一一对应DAL 查询后手动填充到对象里。小项目不引入 ORM 框架也没问题手写参数化 SQL 反而更容易控制锁和事务的边界。3.2 连接串与配置文件环境切换不用动代码把 MySQL 连接串写死在代码里是交付阶段最让人头疼的操作。我一般在App.config中配置connectionStrings add nameTheaterDb connectionStringServer127.0.0.1;Port3306;Databasetheater_db;Uidroot;PwdYourPassword;Charsetutf8mb4;SslModeNone;Allow User Variablestrue;Poolingtrue; providerNameMySql.Data.MySqlClient / /connectionStringsCharsetutf8mb4是防中文乱码的第一步。SslModeNone用于本地开发环境避免 MySQL 8 默认 SSL 配置带来的额外握手开销。Poolingtrue让连接池复用物理连接避免每次操作都重新握手。Allow User Variablestrue是给事务中用到token这类用户变量时准备的开关不是每个项目都需要但如果开发时遇到变量相关的权限报错优先查这里。切换环境时只需要改连接串里的Server、Uid、Pwd代码一行不动。这是我做交付类项目时的默认习惯尤其是剧场现场电脑可能没有安装调试工具配置文件改动比重新编译安全得多。3.3 数据访问基类把参数化查询变成默认习惯DAL 层里我会先写一个静态辅助类把打开连接、执行、释放这套流程收拢到一处。注意这里要放两个ExecuteNonQuery重载一个不传事务一个必须传事务因为业务层一旦开启事务连接和事务对象都要从外部传入不能在方法内部用 using 把连接关掉。using MySql.Data.MySqlClient; using System.Configuration; using System.Data; public static class DbHelper { public static readonly string ConnStr ConfigurationManager.ConnectionStrings[TheaterDb].ConnectionString; /// summary执行增删改返回受影响行数不涉及外部事务/summary public static int ExecuteNonQuery(string sql, params MySqlParameter[] ps) { using (var conn new MySqlConnection(ConnStr)) { conn.Open(); using (var cmd new MySqlCommand(sql, conn)) { if (ps ! null) cmd.Parameters.AddRange(ps); return cmd.ExecuteNonQuery(); } } } /// summary在指定连接和事务上执行增删改/summary public static int ExecuteNonQuery(MySqlConnection conn, MySqlTransaction tx, string sql, params MySqlParameter[] ps) { using (var cmd new MySqlCommand(sql, conn, tx)) { if (ps ! null) cmd.Parameters.AddRange(ps); return cmd.ExecuteNonQuery(); } } /// summary执行查询返回 DataTable/summary public static DataTable ExecuteQuery(string sql, params MySqlParameter[] ps) { using (var conn new MySqlConnection(ConnStr)) { conn.Open(); using (var cmd new MySqlCommand(sql, conn)) { if (ps ! null) cmd.Parameters.AddRange(ps); using (var da new MySqlDataAdapter(cmd)) { var dt new DataTable(); da.Fill(dt); return dt; } } } } }using块保证连接和命令用完后立即释放尤其在连接池模式下不释放连接等于占着池子不还。参数化通过MySqlParameter实现用户输入的任何字符串都只是值不会拼进 SQL从根上杜绝注入。我见过不少新人把字段值直接填进字符串拼接的 SQL 里一个引号就能让整个查询报错这种问题用参数化后自然消失。在 DAL 里查场次列表我一般这样写public DataTable GetScheduleList(DateTime start, DateTime end) { string sql SELECT schedule_id, play_name, start_time, base_price FROM schedule WHERE start_time BETWEEN start AND end ORDER BY start_time; return DbHelper.ExecuteQuery(sql, new MySqlParameter(start, start), new MySqlParameter(end, end)); }这个方法的边界很清楚只负责把数据拉出来不做任何业务计算。上座率、票房统计都放在 BLL 或报表层DAL 保持薄。这样做的好处是如果后边要从 MySQL 换成 SQL ServerDAL 是唯一需要改的层BLL 和 UI 完全不动。3.4 Model 实体与 DataTable 的取舍小项目不必教条理论上看DAL 返回强类型实体是最规范的但在 WinForms DataGridView 的场景下DataTable 能直接作为数据源绑定省去大量手工赋值代码。我的习惯是报表查询返回 DataTable核心事务操作使用实体类。比如锁座、退票这种需要传入多个参数的场景实体类更清晰而“用户选择场次后显示座位表”这种纯展示场景DataTable 直接填表格反而更快。4. 订单核心流程选座、支付、退票、统计四个节点的实现细节4.1 选座并锁定同一个事务里座位和订单一起确认下单入口在 BLL 的TicketService类中。事务边界必须这样画先锁座锁座成功后再插订单和明细全部成功才提交任何一步失败就回滚。如果先插订单后锁座会出现订单已经落库但座位被别人抢走、最终变成“幽灵订单”的情况。public bool BuyTicket(int scheduleId, int seatId, string customerName, out string message) { string token Guid.NewGuid().ToString(N); using (MySqlConnection conn new MySqlConnection(DbHelper.ConnStr)) { conn.Open(); using (MySqlTransaction tx conn.BeginTransaction(IsolationLevel.ReadCommitted)) { try { // 第 1 步尝试锁座影响行数为 0 说明座位已被占用 string lockSql UPDATE seat SET seat_status 1, lock_token token, lock_time NOW() WHERE schedule_id scheduleId AND seat_id seatId AND seat_status 0; int affected DbHelper.ExecuteNonQuery(conn, tx, lockSql, new MySqlParameter(token, token), new MySqlParameter(scheduleId, scheduleId), new MySqlParameter(seatId, seatId)); if (affected ! 1) { message 座位已被锁定或售出请刷新后重选。; tx.Rollback(); return false; } // 第 2 步插入订单主表状态为 1 表示“锁定待支付” string orderSql INSERT INTO orders (schedule_id, customer_name, status, total_amount) VALUES (scheduleId, name, 1, amount); long orderId DbHelper.ExecuteScalar(conn, tx, orderSql, new MySqlParameter(scheduleId, scheduleId), new MySqlParameter(name, customerName), new MySqlParameter(amount, GetTicketPrice(scheduleId, seatId))); // 第 3 步插入订单明细记录这次卖出的座位和价格 string itemSql INSERT INTO order_items (order_id, schedule_id, seat_id, price, status) VALUES (orderId, scheduleId, seatId, amount, 1); DbHelper.ExecuteNonQuery(conn, tx, itemSql, new MySqlParameter(orderId, orderId), new MySqlParameter(scheduleId, scheduleId), new MySqlParameter(seatId, seatId), new MySqlParameter(amount, GetTicketPrice(scheduleId, seatId))); tx.Commit(); message 锁座成功请在十分钟内完成支付。; return true; } catch (Exception ex) { tx.Rollback(); throw new Exception(购票失败事务已回滚。, ex); } } } }这里的ExecuteScalar需要在 DbHelper 里补充一个对应重载作用是把INSERT后生成的order_id返回来。实现并不复杂本质上是执行cmd.ExecuteScalar()并把结果转成long。GetTicketPrice从场次表读取基础票价也可以根据座位区域打折返回值在事务里用两次务必保证一致不要在订单和明细里分别取数。IsolationLevel.ReadCommitted是我在锁座场景下的常用选择。REPEATABLE READ 在普通事务里更安全但锁座业务只需要读到已提交的最新状态降低隔离级别可以减少不必要的间隙锁和死锁机会。lock_token的用途很明确如果用户锁座后弃单系统要靠它来精准释放而不是把其他用户的锁也清掉。4.2 支付与状态流转锁定变已售出的两个 UPDATE锁座不等于售票。用户支付成功后座位从“锁定”变为“已售出”订单从“待支付”变为“已支付”。这两个更新要放在同一个事务里且顺序不能颠倒先确认订单状态再更新座位状态。public bool ConfirmPayment(long orderId, string token) { using (var conn new MySqlConnection(DbHelper.ConnStr)) { conn.Open(); using (var tx conn.BeginTransaction()) { try { // 只有状态为 1锁定待支付且 token 匹配的订单才能支付 string updateOrder UPDATE orders SET status 2, pay_time NOW() WHERE order_id orderId AND status 1 AND lock_token token; int orderAffected DbHelper.ExecuteNonQuery(conn, tx, updateOrder, new MySqlParameter(orderId, orderId), new MySqlParameter(token, token)); if (orderAffected ! 1) { tx.Rollback(); return false; } // 订单支付成功后再更新明细关联的座位状态 string updateSeat UPDATE seat s JOIN order_items oi ON s.seat_id oi.seat_id SET s.seat_status 2, s.lock_token NULL, s.lock_time NULL WHERE oi.order_id orderId; DbHelper.ExecuteNonQuery(conn, tx, updateSeat, new MySqlParameter(orderId, orderId)); tx.Commit(); return true; } catch { tx.Rollback(); throw; } } } }为什么要带status 1 AND lock_token token这个条件因为如果用户重复点击“支付”第二次进来时订单已经变成状态 2条件不满足影响行数为 0代码会直接返回 false不会把座位状态再刷一遍。lock_token不单是座位释放凭证也是支付环节防止重复操作的护身符。4.3 退票与释放订单、明细、座位三处要一起改退票看起来是锁座的逆操作但涉及的数据比买票还多。只把座位状态改回 0 的做法不够严谨因为订单状态还停在“已支付”后面对账时会出现“订单显示已付款但座位已经空闲”的脏数据。规范的退票逻辑要同时改三处订单状态改为已退票订单明细状态改为已退座位状态改回空闲。public bool RefundTicket(long orderId, int scheduleId, int seatId, decimal refundAmount) { using (var conn new MySqlConnection(DbHelper.ConnStr)) { conn.Open(); using (var tx conn.BeginTransaction()) { try { // 订单主表记录退票状态和退款金额 DbHelper.ExecuteNonQuery(conn, tx, UPDATE orders SET status 4, refund_amount amt, refund_time NOW() WHERE order_id orderId, new MySqlParameter(amt, refundAmount), new MySqlParameter(orderId, orderId)); // 订单明细标记为已退保留历史记录 DbHelper.ExecuteNonQuery(conn, tx, UPDATE order_items SET status 2 WHERE order_id orderId AND seat_id seatId, new MySqlParameter(orderId, orderId), new MySqlParameter(seatId, seatId)); // 座位恢复空闲清空锁信息 DbHelper.ExecuteNonQuery(conn, tx, UPDATE seat SET seat_status 0, lock_token NULL, lock_time NULL WHERE schedule_id scheduleId AND seat_id seatId, new MySqlParameter(scheduleId, scheduleId), new MySqlParameter(seatId, seatId)); tx.Commit(); return true; } catch { tx.Rollback(); throw; } } } }退票金额从哪来一般直接取订单明细里的price字段。如果系统支持折扣码、会员价等优惠最好在订单主表里存一个refundable_amount退票时直接减这个字段不要在业务层用total_amount做算术再推断明细那样很容易因为除不尽产生一分钱误差。整体来看退票事务只有一个原则要么三处全改要么一处都不改绝不允许出现中间状态。4.4 统计报表上座率、票房与剧目热度的两种口径报表层最常被问到的问题是“上座率怎么算”。如果简单用“当前已售座位数 / 总座位数”退票之后数字就会变小客户会觉得数据不对。我的口径是“该场次历史卖出座位数 / 总座位数”其中历史卖出数来自order_items.status1的记录退票后明细状态改为 2 不影响这个统计。SELECT s.schedule_id, s.play_name, COUNT(DISTINCT oi.seat_id) AS sold_seats, (SELECT COUNT(*) FROM seat WHERE seat.schedule_id s.schedule_id) AS total_seats, ROUND(COUNT(DISTINCT oi.seat_id) * 100.0 / (SELECT COUNT(*) FROM seat WHERE seat.schedule_id s.schedule_id), 2) AS fill_rate FROM schedule s LEFT JOIN order_items oi ON oi.schedule_id s.schedule_id AND oi.status 1 WHERE s.start_time BETWEEN start AND end GROUP BY s.schedule_id;票房统计则直接对orders表做聚合但过滤条件要谨慎订单状态为 2已支付的收入才计入票房状态 1 还在锁定中状态 4 是已退票都不能算。如果一场演出支持改签改签后的新订单也应计入当次票房这时需要在订单表里加一个source_order_id字段改签时把原订单号关联进去方便对账。拿到 DataTable 后WinForms 端绑定 DataGridView 非常直接dataGridView1.DataSource reportService.GetFillRateReport(startDate, endDate); dataGridView1.AutoResizeColumns(DataGridViewAutoSizeColumnsMode.AllCells);统计查询不需要经历 UI 线程来回请求因为它是同步拉数据。如果数据量大到界面卡顿再考虑加一层异步加载但这个小系统的业务量通常不需要。5. 避坑排查中文乱码、连接超时、死锁和驱动版本冲突5.1 中文乱码连接串、表、服务端三处不统一现象数据库里存的数据变成???或者读出来变成乱码重开客户端偶尔正常。原因MySQL 服务端默认字符集、连接串的Charset、表字段字符集三者必须保持一致。很多开发只改了建表语句为 utf8mb4连接串里还是老的latin1数据入库前已经被转码。MySQL 8 默认字符集虽然已经是 utf8mb4但旧项目遗留的连接串并不会自动跟随。解决统一三处配置。先改连接串加Charsetutf8mb4再修改已存在的表“ALTER TABLE seat CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;”。同时检查 MySQL 配置文件里character-set-serverutf8mb4。一句话只要涉及中文写入先把这三处对齐再看代码。5.2 连接超时8 小时 wait_timeout 与连接池的矛盾现象系统隔了一晚上第二天第一次查询报“连接已丢失”或“Dead connection”第二次操作又恢复正常。原因MySQL 的wait_timeout默认是 8 小时长时间没有活动的连接会被服务端关闭。C# 连接池里缓存的连接已经失效客户端取出来用时没有及时发现第一次命令就失败。第二次连接池会重建物理连接所以又正常了。解决给连接串加Poolingtrue同时在程序启动时执行一次SELECT 1探活查询把失效连接提前清除。更彻底的方案是把连接串的Connection Lifetime设为 120 秒让连接池主动丢弃存活太久的连接避开服务端 8 小时限制。代码里每个MySqlConnection必须放在 using 块中不要搞全局单例连接这一条能从根上规避大部分超时问题。5.3 死锁多座位订单需要统一锁定顺序现象一次选 5 个座位并发下单时日志抛出Deadlock found when trying to get lock; try restarting transaction整个事务回滚。原因两个事务同时锁定座位集合时一个事务先锁 5 号位再锁 10 号位另一个事务先锁 10 号位再锁 5 号位两个事务各自持有一把锁并等待对方的锁形成死锁。MySQL 检测到死锁会牺牲其中一个事务应用层就会看到这个异常。解决在代码强制固定锁的顺序。最简单的方法是把要锁的座位 ID 升序排序后再依次执行 UPDATE或者一次性锁住该订单涉及的所有座位UPDATE seat SET seat_status 1, lock_token token, lock_time NOW() WHERE schedule_id scheduleId AND seat_id IN (5, 10, 12) AND seat_status 0;IN子句把多行锁作为一个整体请求存储引擎统一处理顺序死锁概率大幅下降。需要注意的是一次IN的座位数量不要超过一个订单实际涉及的座位数比如一个订单最多 5 张票就不要把 20 个座位塞进一条更新语句否则长时间占用行锁会让其他购票请求等待。5.4 驱动版本MySQL 8 认证方式让老驱动翻车现象连接 MySQL 8.0 时抛异常Authentication method caching_sha2_password not supported by any of the available plugins。原因MySQL 8 默认认证插件是caching_sha2_password而较老版本的 MySql.Data 驱动只支持mysql_native_password。项目引用的驱动版本太老握手阶段就会失败连后面执行 SQL 的机会都没有。解决优先升级 MySql.Data 到 8.0.20 以上版本新驱动对两种认证方式都兼容。如果因为某些原因无法升级可以给项目单独创建一个使用老认证方式的用户CREATE USER appuser% IDENTIFIED WITH mysql_native_password BY yourpassword; GRANT ALL PRIVILEGES ON theater_db.* TO appuser%; FLUSH PRIVILEGES;这属于临时方案新驱动本身就支持新认证直接升级更省心。5.5 界面假可售事务隔离的“快照”带给用户的错觉现象客户端 A 锁座后客户端 B 仍然显示该座位可售用户点击下单才提示“座位已被锁定”。原因座位表状态确实被 A 更新了但 B 界面用了本地缓存或旧查询结果。也可能 B 的事务开启时间早于 A 的提交时间在 REPEATABLE READ 下事务内的快照读保持一致B 看到的是自己事务开始时的座位状态。解决选座页面每次打开或点击“刷新座位”时强制发起新查询不在客户端维护座位状态缓存。锁座失败时把对应座位在界面标记为灰提示用户已被人锁定。如果担心刷新闪烁可以只更新座位状态列不要重建整个表格。这个提示看起来简单却是交付时被客户投诉最多的点之一尤其当剧场前台用了两台电脑卖票时一台卖出座位另一台还显示可售。6. 交付前模拟并发压测三个验证点与一个日志兜底6.1 控制台并发脚本不开界面也能压力测试由于 BLL 层是独立的压测不需要打开 WinForms。新建一个控制台项目引用Theater.BLL用多线程模拟 20 个顾客同时抢票。关键是每个线程都用单独的任务和座位 ID这样能测出数据库事务并发下的真实表现class Program { static void Main() { var service new TicketService(); var threads new ListThread(); for (int i 0; i 20; i) { int seatId 30 i; var t new Thread(() { bool ok service.BuyTicket(1, seatId, $test_{seatId}, out string msg); Console.WriteLine(${DateTime.Now:HH:mm:ss.fff} seat{seatId} result{ok} msg{msg}); }); t.Start(); threads.Add(t); } foreach (var t in threads) t.Join(); Console.WriteLine(压测结束请检查订单表和座位表数据一致性。); } }如果想把并发压得更狠可以把所有线程都用同一个seatId专门验证超卖防护是否能拦住重复购买。正常逻辑下20 个线程只有 1 个能成功其余 19 个都会收到“座位已被锁定或售出”。在这种场景里重点观察数据库报错数量如果出现重复成功记录说明事务边界有问题需要立刻检查锁座 SQL。6.2 三个验证点无超卖、无锁残留、响应时间可控压测脚本跑完后我基本只查三个地方。第一order_items表里同一个schedule_id seat_id是否重复重复即超卖这是必须为零的硬指标。第二seat表里seat_status1且lock_time已超过十分钟的记录数量如果有残留说明超时回收任务没触发或锁释放逻辑漏了分支。第三统计控制台里每条线程从发出请求到返回结果的时间超过 500ms 的请求比例不能太高。小剧场单场几百张票事务型业务 90% 请求落在 100ms 内比较合理如果大量超过 500ms优先怀疑锁等待再检查索引是否命中。6.3 日志文件兜底回滚失败时能快速定位最后一步是日志。小型项目没有 ELK 这类日志中心但至少要有一个本地文件日志记录关键事务的入参、异常堆栈和回滚结果。我习惯在 BLL 层给公共方法加统一异常捕获catch (Exception ex) { File.AppendAllText(logs/ticket_error.log, ${DateTime.Now:yyyy-MM-dd HH:mm:ss} seat{seatId} schedule{scheduleId} err{ex}\r\n); throw; }日志文件名按日期滚动排查某天的脏数据时直接打开对应文件即可。第一次做这个项目时我以为锁座失败直接抛异常就行结果上线后用户反馈“提示购票失败但订单表里多了记录”最后靠日志定位到订单插入后座位更新失败事务回滚没执行完整。从那以后每次交付前我都会强制走一遍并发压测脚本、三个验证点和日志检查确认无误后再交给客户部署。希望这套流程也能帮你少踩几个坑。本文还有配套的精品资源点击获取
