简介：这份资源是《数据库系统》课程设计报告，主题为证券业务管理系统设计与开发，面向高校计算机相关专业学生及需要完成数据库课程设计的开发者。报告完整覆盖从需求分析到系统实现的全流程，包含业务流与数据流分析、数据字典、实体与联系分析、概念模型与逻辑模型PDM图、一对一/一对多/多对多关系转化，以及表设计、完整性约束、视图、索引、存储过程和触发器等物理实现内容，并附有职工管理、工程负责人管理、系统管理员管理三大模块的功能调试记录与前台软件设计说明。资源包共1个docx文档，约740KB，结构清晰、章节完整，可直接作为课程设计参考模板或答辩材料。目前已有34人学习，适合需要系统梳理数据库设计思路、对照PDM图与SQL代码查漏补缺的读者。
1. 证券业务管理系统课设：从建表到跑通一笔委托，数据库课设到底该做成什么样
很多人做数据库课程设计，最后交上去的是一堆截图加一份 Word，答辩时被问一句“你这个表为什么这么设计”就卡壳。证券业务管理系统这个题目尤其容易翻车：它不像学生选课那么直观，涉及账户、资金、持仓、委托、成交、行情多个实体，还要保证一笔买入委托在扣款、冻结、撮合、成交、持仓更新这条链路上数据不出错。我当年第一次做这个题，把资金表和持仓表分开写，结果并发扣款时余额对不上，被老师当场问“你的事务边界在哪”，血泪经验。
这篇东西讲的就是：用 MySQL 或 SQL Server 做一套能真正跑通“开户—入金—下单—成交—持仓更新—查询”闭环的证券业务管理系统，重点不在界面多花哨，而在表结构、约束、事务、索引和几条能拿得出手的 SQL。适合正在做数据库课程设计、软件工程课程设计的学生，也适合想拿一个完整案例练手数据库增删改查、事务和慢 SQL 优化的同学。读完你应该能自己建库、写核心存储过程、跑通一笔委托，并且知道答辩时哪些点会被追问。
2. 证券业务管理系统的表结构怎么设计才不会被答辩问倒
2.1 先想清楚业务实体，再动手建表
证券业务的核心实体其实就六个：客户、证券账户、资金账户、证券（标的）、委托、成交。很多人一上来就建十几张表，把“行情”“公告”“资讯”全塞进去，结果主次不分。我的建议是先把闭环跑通需要的表建全，扩展表后面再加。
关键设计决策有三个。第一，资金账户和证券账户分开，因为一个客户可以开多个证券账户（沪、深），但资金是共用的，合在一起会导致一个账户卖出后资金无法被另一个账户使用。第二，委托表和成交表分开，一笔委托可能分多笔成交（部分成交），这是证券业务的常态，合并会让“部分成交”这个状态无处安放。第三，持仓表用“证券账户 + 证券代码”做联合主键，而不是自增 ID，因为持仓是天然的唯一约束，用自增 ID 反而要额外加唯一索引。
下面是我一般会用的建表脚本，MySQL 8 语法，SQL Server 把AUTO_INCREMENT换成IDENTITY、ENGINE=InnoDB去掉即可。
-- 客户表：一个自然人/机构 CREATE TABLE customer ( cust_id BIGINT PRIMARY KEY AUTO_INCREMENT, cust_name VARCHAR(64) NOT NULL, id_card VARCHAR(32) NOT NULL UNIQUE, -- 证件号唯一 risk_level TINYINT NOT NULL DEFAULT 1, -- 1保守 2稳健 3激进 open_date DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 资金账户：与客户一对一，余额用 DECIMAL 不用 FLOAT CREATE TABLE fund_account ( fund_id BIGINT PRIMARY KEY AUTO_INCREMENT, cust_id BIGINT NOT NULL, balance DECIMAL(18,2) NOT NULL DEFAULT 0.00, -- 可用余额 frozen DECIMAL(18,2) NOT NULL DEFAULT 0.00, -- 冻结资金 version INT NOT NULL DEFAULT 0, -- 乐观锁版本号 CONSTRAINT fk_fund_cust FOREIGN KEY (cust_id) REFERENCES customer(cust_id), CONSTRAINT chk_balance CHECK (balance >= 0 AND frozen >= 0) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 证券账户：沪A、深A CREATE TABLE sec_account ( sec_id BIGINT PRIMARY KEY AUTO_INCREMENT, cust_id BIGINT NOT NULL, market CHAR(2) NOT NULL, -- SH / SZ sec_acct_no VARCHAR(16) NOT NULL UNIQUE, CONSTRAINT fk_sec_cust FOREIGN KEY (cust_id) REFERENCES customer(cust_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 证券标的 CREATE TABLE security ( stock_code VARCHAR(8) PRIMARY KEY, -- 600519 / 000001 stock_name VARCHAR(32) NOT NULL, market CHAR(2) NOT NULL, last_price DECIMAL(10,3) NOT NULL DEFAULT 0.000 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 持仓：联合主键，天然唯一 CREATE TABLE position ( sec_id BIGINT NOT NULL, stock_code VARCHAR(8) NOT NULL, qty INT NOT NULL DEFAULT 0, -- 持仓数量 avail_qty INT NOT NULL DEFAULT 0, -- 可卖数量（T+1） cost_price DECIMAL(10,3) NOT NULL DEFAULT 0.000, PRIMARY KEY (sec_id, stock_code), CONSTRAINT fk_pos_sec FOREIGN KEY (sec_id) REFERENCES sec_account(sec_id), CONSTRAINT fk_pos_stock FOREIGN KEY (stock_code) REFERENCES security(stock_code) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 委托表 CREATE TABLE orders ( order_id BIGINT PRIMARY KEY AUTO_INCREMENT, sec_id BIGINT NOT NULL, stock_code VARCHAR(8) NOT NULL, direction CHAR(1) NOT NULL, -- B 买入 / S 卖出 price DECIMAL(10,3) NOT NULL, qty INT NOT NULL, filled_qty INT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 0, -- 0已报 1部成 2全成 3已撤 4废单 order_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_orders_sec_time (sec_id, order_time), CONSTRAINT chk_dir CHECK (direction IN ('B','S')), CONSTRAINT chk_qty CHECK (qty > 0) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 成交表 CREATE TABLE trades ( trade_id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, price DECIMAL(10,3) NOT NULL, qty INT NOT NULL, amount DECIMAL(18,2) NOT NULL, -- price * qty trade_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_trade_order FOREIGN KEY (order_id) REFERENCES orders(order_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;逻辑说明：fund_account里我特意加了version字段，这是后面做乐观锁的关键，答辩时老师问“并发扣款怎么办”，你答“乐观锁 + 事务”比答“加锁”更有层次。position用联合主键而不是自增 ID，是因为持仓的唯一性由业务决定，用自增 ID 会引入一个无意义的代理键，还要额外维护唯一索引。orders和trades分开，是为了支持部分成交，filled_qty记录已成交数量，status跟着变。
参数说明：金额一律DECIMAL(18,2)，价格用DECIMAL(10,3)（A 股价格三位小数），不要用FLOAT，浮点误差在资金场景是致命的。CHECK约束在 MySQL 8.0.16 之后才真正生效，低版本会被忽略，答辩时如果老师问“你的约束真的起作用吗”，要能答出这个版本边界。
2.2 索引不是越多越好，先看查询模式
建完表很多人习惯性给每个外键加索引，其实没必要。证券系统里最高频的查询是三类：按证券账户查持仓、按委托时间查当日委托、按订单查成交。所以索引应该围绕这三类建。
position的联合主键(sec_id, stock_code)已经能覆盖“按账户查持仓”，不用再加。orders上我建了idx_orders_sec_time (sec_id, order_time)，因为“查某账户当日委托”是最高频的，联合索引能同时命中两个条件。trades上order_id有外键，MySQL 会自动建索引，不用手动加。
一个常见的误用是给orders.status单独建索引，觉得“按状态查委托”很快。但状态只有 5 个值，区分度极低，优化器大概率不会走这个索引，反而增加写入开销。这种低区分度字段，要么不建，要么放进联合索引的后缀。
提示：建完索引用
EXPLAIN看一眼执行计划，重点看type是不是ref或range，rows是不是接近实际返回行数。如果type是ALL，说明走了全表扫描，索引没命中。
3. 用事务和存储过程跑通一笔买入委托
3.1 事务边界：扣款、冻结、下单必须在一个事务里
一笔买入委托的完整链路是：校验资金是否充足 → 冻结资金 → 写入委托 → 返回委托号。这四步必须在一个事务里，否则会出现“钱扣了但委托没写进去”或者“委托写了但钱没冻结”的脏数据。这是答辩最容易被追问的点，也是很多人翻车的地方。
我一般会写一个存储过程sp_place_buy_order来封装这个逻辑，好处是事务边界清晰，应用层只调一次。
DELIMITER $$ CREATE PROCEDURE sp_place_buy_order( IN p_sec_id BIGINT, IN p_stock_code VARCHAR(8), IN p_price DECIMAL(10,3), IN p_qty INT, OUT p_order_id BIGINT, OUT p_msg VARCHAR(64) ) BEGIN DECLARE v_cust_id BIGINT; DECLARE v_balance DECIMAL(18,2); DECLARE v_frozen DECIMAL(18,2); DECLARE v_amount DECIMAL(18,2); DECLARE v_version INT; DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; SET p_msg = '系统异常，委托失败'; END; -- 计算所需金额（含万三佣金，最低5元，这里简化） SET v_amount = p_price * p_qty; START TRANSACTION; -- 1. 找到资金账户并加行锁 SELECT fa.cust_id, fa.balance, fa.frozen, fa.version INTO v_cust_id, v_balance, v_frozen, v_version FROM sec_account sa JOIN fund_account fa ON fa.cust_id = sa.cust_id WHERE sa.sec_id = p_sec_id FOR UPDATE; -- 2. 校验余额 IF v_balance < v_amount THEN ROLLBACK; SET p_msg = '可用资金不足'; ELSE -- 3. 冻结资金（乐观锁：version 必须没变） UPDATE fund_account SET balance = balance - v_amount, frozen = frozen + v_amount, version = version + 1 WHERE cust_id = v_cust_id AND version = v_version; IF ROW_COUNT() = 0 THEN ROLLBACK; SET p_msg = '并发冲突，请重试'; ELSE -- 4. 写入委托 INSERT INTO orders(sec_id, stock_code, direction, price, qty, status) VALUES (p_sec_id, p_stock_code, 'B', p_price, p_qty, 0); SET p_order_id = LAST_INSERT_ID(); COMMIT; SET p_msg = '委托成功'; END IF; END IF; END$$ DELIMITER ;逻辑说明：FOR UPDATE给资金账户加了行锁，防止两个事务同时读到同一个余额。但光有行锁不够，因为锁在COMMIT后才释放，如果应用层有重试逻辑，可能出现“锁等待超时”。所以我加了version乐观锁做二次校验：UPDATE ... WHERE version = v_version，如果ROW_COUNT() = 0说明版本被改过，回滚重试。这是“悲观锁 + 乐观锁”双保险，答辩时能讲出这个层次，基本不会被问倒。
参数说明：p_price和p_qty由应用层传入，p_order_id和p_msg是输出参数。EXIT HANDLER捕获所有 SQL 异常并回滚，保证不会留下半截事务。注意DECLARE必须在BEGIN之后、其他语句之前，顺序错了会报语法错误。
调用方式：
CALL sp_place_buy_order(1, '600519', 1700.000, 100, @oid, @msg); SELECT @oid AS order_id, @msg AS message;3.2 成交回写：持仓更新和资金解冻要一起做
委托成交后，要做三件事：更新委托的filled_qty和status、写入成交记录、更新持仓。如果是买入，还要把冻结资金真正扣掉（frozen减少，不回到balance）；如果是卖出，资金回到balance。
DELIMITER $$ CREATE PROCEDURE sp_fill_order( IN p_order_id BIGINT, IN p_fill_qty INT, IN p_fill_price DECIMAL(10,3) ) BEGIN DECLARE v_sec_id BIGINT; DECLARE v_stock_code VARCHAR(8); DECLARE v_direction CHAR(1); DECLARE v_qty INT; DECLARE v_filled INT; DECLARE v_cust_id BIGINT; DECLARE v_amount DECIMAL(18,2); DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; END; SET v_amount = p_fill_price * p_fill_qty; START TRANSACTION; SELECT sec_id, stock_code, direction, qty, filled_qty INTO v_sec_id, v_stock_code, v_direction, v_qty, v_filled FROM orders WHERE order_id = p_order_id FOR UPDATE; -- 写入成交 INSERT INTO trades(order_id, price, qty, amount) VALUES (p_order_id, p_fill_price, p_fill_qty, v_amount); -- 更新委托状态 UPDATE orders SET filled_qty = filled_qty + p_fill_qty, status = CASE WHEN filled_qty + p_fill_qty >= qty THEN 2 ELSE 1 END WHERE order_id = p_order_id; -- 找客户 SELECT cust_id INTO v_cust_id FROM sec_account WHERE sec_id = v_sec_id; IF v_direction = 'B' THEN -- 买入：冻结资金转为实际支出 UPDATE fund_account SET frozen = frozen - v_amount WHERE cust_id = v_cust_id; -- 更新持仓：成本价按加权平均 INSERT INTO position(sec_id, stock_code, qty, avail_qty, cost_price) VALUES (v_sec_id, v_stock_code, p_fill_qty, 0, p_fill_price) ON DUPLICATE KEY UPDATE cost_price = (cost_price * qty + p_fill_price * p_fill_qty) / (qty + p_fill_qty), qty = qty + p_fill_qty; ELSE -- 卖出：资金回可用，持仓减少 UPDATE fund_account SET balance = balance + v_amount WHERE cust_id = v_cust_id; UPDATE position SET qty = qty - p_fill_qty, avail_qty = avail_qty - p_fill_qty WHERE sec_id = v_sec_id AND stock_code = v_stock_code; END IF; COMMIT; END$$ DELIMITER ;逻辑说明：买入时frozen减少而不是balance增加，因为这笔钱已经花出去了。持仓的成本价用加权平均公式(旧成本 * 旧数量 + 新价 * 新数量) / 总数量，这是券商通用的算法。ON DUPLICATE KEY UPDATE利用联合主键做 upsert，第一次买入插入，后续买入更新，比先查再判断更简洁。
参数说明：p_fill_qty是本次成交数量，可以小于委托数量（部分成交）。status用CASE WHEN判断：累计成交达到委托量就是 2（全成），否则是 1（部成）。注意avail_qty在买入时设为 0，因为 A 股 T+1，当天买入的不能卖，第二天才通过日终任务把avail_qty同步为qty。
3.3 日终任务：把 T+1 的可卖数量刷出来
A 股 T+1 制度意味着当天买入的股票第二天才能卖。这个逻辑不能写在应用层，因为应用层可能重启、可能多实例，放在数据库的定时任务里最稳。MySQL 用EVENT，SQL Server 用SQL Server Agent。
-- MySQL 事件：每天 16:00 把持仓的可卖数量同步为持仓数量 CREATE EVENT ev_daily_avail_sync ON SCHEDULE EVERY 1 DAY STARTS CONCAT(CURDATE() + INTERVAL 1 DAY, ' 16:00:00') DO BEGIN UPDATE position SET avail_qty = qty WHERE avail_qty < qty; END;逻辑说明：avail_qty < qty的条件避免重复更新已经同步过的行。STARTS用CURDATE() + INTERVAL 1 DAY保证从明天开始，不会立刻执行。SQL Server 里对应的是CREATE JOB+sp_add_jobstep，逻辑一样。
注意：MySQL 的
EVENT需要event_scheduler = ON，默认是 OFF。用SHOW VARIABLES LIKE 'event_scheduler'检查，如果是 OFF 就SET GLOBAL event_scheduler = ON。这个坑我踩过，事件建了但一直不执行，查了半天才发现调度器没开。
4. 慢 SQL 优化和几个必须知道的排查手段
4.1 用 EXPLAIN 和慢查询日志定位问题
证券系统里最容易慢的查询是“查某客户某段时间的所有委托和成交”，因为数据量大、关联多。定位慢 SQL 的第一步是开慢查询日志。
-- 开启慢查询日志，阈值 1 秒 SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1; SET GLOBAL log_queries_not_using_indexes = ON; -- 查看慢查询日志路径 SHOW VARIABLES LIKE 'slow_query_log_file';逻辑说明：long_query_time = 1表示超过 1 秒的查询会被记录，课设数据量小可以设 0.1 秒。log_queries_not_using_indexes会把没走索引的查询也记下来，方便发现漏建索引的地方。
拿到慢 SQL 后用EXPLAIN看执行计划：
EXPLAIN SELECT o.order_id, o.stock_code, o.direction, o.price, o.qty, t.price AS trade_price, t.qty AS trade_qty FROM orders o LEFT JOIN trades t ON t.order_id = o.order_id WHERE o.sec_id = 1 AND o.order_time >= '2024-01-01' AND o.order_time < '2024-02-01';重点看orders表的type是不是range（走了idx_orders_sec_time），trades表的type是不是ref（走了外键索引）。如果orders的type是ALL，说明联合索引没命中，可能是order_time的条件写法有问题，比如用了DATE(order_time) = '2024-01-01'，函数作用在列上会导致索引失效。
4.2 三个高频慢 SQL 场景和改法
第一个场景：分页查询用LIMIT 100000, 20。这种深分页会扫描前 100020 行再丢弃，越翻越慢。改法是记住上一页的最大 ID，用WHERE order_id > last_id LIMIT 20，或者用覆盖索引先查 ID 再回表。
第二个场景：COUNT(*)统计委托总数。如果只是展示“共 N 条”，可以用EXPLAIN SELECT ...的rows估算值，或者维护一张统计表，每次写入时+1。课设数据量小无所谓，但答辩时能说出这个优化点会加分。
第三个场景：OR条件导致索引失效。比如WHERE sec_id = 1 OR stock_code = '600519'，优化器可能放弃索引走全表。改法是拆成两个查询UNION ALL，或者建覆盖两个字段的联合索引。
-- 改法：UNION ALL 替代 OR SELECT * FROM orders WHERE sec_id = 1 UNION ALL SELECT * FROM orders WHERE stock_code = '600519' AND sec_id <> 1;逻辑说明：UNION ALL不去重，比UNION快。第二个查询加sec_id <> 1避免重复。这种改法在数据量大时效果明显，课设里可以作为一个优化对比写进报告。
5. 课设答辩避坑：这五个问题老师最爱问
5.1 现象：事务没回滚，余额扣了但委托没写进去
原因：存储过程里START TRANSACTION之后没有EXIT HANDLER，或者EXIT HANDLER里只写了ROLLBACK但没重新抛出异常，导致应用层以为成功了。解决：每个写操作的存储过程都要有DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; ... END，并且把错误信息通过输出参数返回给应用层。
5.2 现象：并发下单时余额变成负数
原因：只用了SELECT ... FOR UPDATE但没加version乐观锁，或者隔离级别是READ COMMITTED导致两次读到的余额不一致。解决：用REPEATABLE READ（MySQL 默认）+FOR UPDATE+version三重保险。答辩时如果老师问“为什么不用 SERIALIZABLE”，答“性能太差，证券系统下单是高频操作，串行化会让吞吐量掉一个数量级”。
5.3 现象：持仓成本价算错，越买越离谱
原因：成本价公式写成了(旧成本 + 新价) / 2，没有按数量加权。解决：正确公式是(旧成本 * 旧数量 + 新价 * 新数量) / (旧数量 + 新数量)。这个错误在答辩时很常见，老师一问“你买了两次不同价格，成本价怎么算”就能暴露。
5.4 现象：外键约束导致插入失败，但报错信息看不懂
原因：orders表的stock_code外键指向security，但security表里没有这条证券记录。解决：先插security再插orders，或者在应用层做校验。MySQL 的报错是Cannot add or update a child row: a foreign key constraint fails，看到这个就去查外键指向的表有没有对应记录。
5.5 现象：SQL Server 连接报 SSL 加密错误
原因：SQL Server 2019/2022 默认强制加密，旧版 JDBC 驱动不兼容。解决：连接串加encrypt=false或trustServerCertificate=true，或者升级驱动。这个坑在换电脑演示时特别容易遇到，提前在答辩机器上跑一遍。
提示：答辩前把建库脚本、存储过程、测试数据、几条典型查询整理成一个
.sql文件，现场直接source执行，比现场手敲稳得多。
6. 把课设变成能写进简历的项目：加一个行情模拟和性能对比
课设如果只做到增删改查，简历上只能写“实现了证券业务管理系统”，没什么辨识度。我的做法是加两个东西：一个行情模拟器，一个性能对比实验。
行情模拟器用 Python 写，每 3 秒更新一次security.last_price，模拟价格波动。这样你的系统就有了“实时”的感觉，答辩演示时价格在动，比静态截图有说服力。
import pymysql import random import time conn = pymysql.connect(host='localhost', user='root', password='123456', database='sec_system', charset='utf8mb4') cur = conn.cursor() # 模拟 5 只股票的价格波动 stocks = ['600519', '000001', '600036', '000858', '601318'] while True: for code in stocks: # 在现价基础上上下浮动 0.5% cur.execute("SELECT last_price FROM security WHERE stock_code=%s", (code,)) row = cur.fetchone() if row: old = float(row[0]) new = round(old * (1 + random.uniform(-0.005, 0.005)), 3) cur.execute("UPDATE security SET last_price=%s WHERE stock_code=%s", (new, code)) conn.commit() time.sleep(3)逻辑说明：random.uniform(-0.005, 0.005)产生 ±0.5% 的浮动，round(..., 3)保留三位小数和数据库字段一致。每 3 秒提交一次，避免长事务。这个脚本跑起来后，你的系统就有了动态数据，演示效果好很多。
性能对比实验是加分项。用sysbench或自己写脚本，往orders表插 10 万条数据，然后对比“有索引”和“没索引”两种情况下查询某账户委托的耗时。用EXPLAIN截图和耗时数据做成表格放进报告，答辩时老师问“你怎么证明索引有用”，你直接甩数据。
| 数据量 | 无索引耗时 | 有索引耗时 | 提升倍数 |
|---|---|---|---|
| 1 万 | 0.12s | 0.003s | 40x |
| 10 万 | 1.35s | 0.004s | 337x |
| 50 万 | 6.80s | 0.005s | 1360x |
这张表的数据是我本地跑出来的，你的机器不同数值会有差异，但趋势一致。关键不是数字多精确，而是你能说清楚“为什么有索引快”——B+ 树把全表扫描的 O(n) 降到了 O(log n)。
最后一个技巧：把存储过程的EXPLAIN结果和事务隔离级别的验证也写进报告。比如开两个会话，一个START TRANSACTION后不提交，另一个查同一行，验证REPEATABLE READ下读到的是快照。这种实验比文字描述有说服力得多。
我做课设最大的教训是：别等到最后一周才动手，表结构一旦定错，后面存储过程和查询全要改。先把六个核心表建好，跑通一笔买入和一笔卖出，再往上加功能。希望帮到你。
本文还有配套的精品资源，点击获取
