简介这份资源是一套基于C#与SQL Server 2019开发的餐饮外卖销售系统数据库设计面向高校数据库课程设计的学生及需要实战练手的初学者。系统划分商家、客户、骑手三类用户界面并配有注册模块采用扁平化设计界面达到商业软件水准可作为课设满分参考模板。压缩包共46个文件约886KB以13个cs源码文件为核心辅以resx资源、config配置、jpg界面截图及sln解决方案等配置好环境后可直接用Visual Studio打开运行。代码结构清晰、注释详细登录、注册、商家与客户等模块划分明确便于读者理解数据库表设计与界面交互逻辑。目前已有1593人学习下载适合希望快速掌握C#与SQL Server结合开发、并完成一份高质量数据库课设的读者参考借鉴。1. 餐饮外卖销售系统数据库设计从一张订单表说起很多人第一次接触餐饮外卖销售系统数据库设计是从一张orders表开始的。看起来无非是用户、商家、菜品、订单四个实体画个 ER 图就能交差。但真正跑过业务的人知道外卖场景的数据库设计难点根本不在实体关系而在高频写入下的订单状态流转、菜品规格与价格的动态绑定、以及骑手调度与配送时效的数据建模。一个设计不当的order_detail表在午高峰每秒几百单的写入压力下就能让整个系统响应从 200ms 飙到 3s。这篇文章面向的是需要从零搭建或重构外卖系统数据层的开发者我会把表结构、索引策略、状态机设计、分库分表边界这些落地细节拆开讲让你能直接照着建表、写查询、避坑。2. 外卖业务的数据模型拆解与表结构设计2.1 为什么不能照搬电商的 SKU 模型电商的 SKU 模型是「商品-规格-库存」三层用户下单时锁定库存。外卖不一样菜品有做法备注少辣、去葱、套餐组合主食饮料小食、时段价格午市价和晚市价不同而且库存不是核心约束——卖完了直接下架不需要超卖控制。如果硬套电商 SKU 表你会得到一张字段爆炸的dish_sku表里面塞满is_spicy、has_onion这种布尔列扩展性极差。我一般会拆成四张核心表dish菜品基础信息、dish_spec规格组如份量、辣度、dish_spec_option规格选项如大份/小份、微辣/中辣、dish_price价格规则按时段或会员等级。订单侧用order_item记录快照把下单时的菜品名、规格、单价全部冗余进去避免历史订单因菜品改价而金额错乱。-- 菜品规格组一个菜品可以有多个规格维度 CREATE TABLE dish_spec ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, dish_id BIGINT UNSIGNED NOT NULL COMMENT 菜品ID, spec_name VARCHAR(32) NOT NULL COMMENT 规格名如份量、辣度, is_required TINYINT NOT NULL DEFAULT 0 COMMENT 是否必选, sort_order INT NOT NULL DEFAULT 0, KEY idx_dish (dish_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT菜品规格组; -- 规格选项每个规格组下的可选项 CREATE TABLE dish_spec_option ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, spec_id BIGINT UNSIGNED NOT NULL, option_name VARCHAR(32) NOT NULL COMMENT 选项名如大份、微辣, price_delta INT NOT NULL DEFAULT 0 COMMENT 加价金额单位分, KEY idx_spec (spec_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT规格选项;这里price_delta用整数存分避免浮点误差。is_required控制前端是否强制选择比如份量必选、辣度可选。排序字段让前端展示顺序可控。2.2 订单主表与明细表的字段取舍订单主表orders要扛住高频写入字段越少越好。核心字段order_no业务单号唯一索引、user_id、shop_id、rider_id、status状态机、total_amount、pay_amount、created_at、paid_at、delivered_at。注意不要在主表放菜品详情那是明细表的事。明细表order_item的关键是快照冗余dish_name、spec_desc、unit_price、quantity、item_amount全部存下单时的值。这样即使菜品改名改价历史订单依然准确。我见过有团队为了「节省空间」只存dish_id结果菜品下架后订单详情页直接空白客服被投诉到崩溃。CREATE TABLE orders ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL COMMENT 业务单号, user_id BIGINT UNSIGNED NOT NULL, shop_id BIGINT UNSIGNED NOT NULL, rider_id BIGINT UNSIGNED DEFAULT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已接单 3配送中 4已完成 5已取消, total_amount INT NOT NULL COMMENT 商品总额单位分, pay_amount INT NOT NULL COMMENT 实付金额单位分, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, paid_at DATETIME DEFAULT NULL, delivered_at DATETIME DEFAULT NULL, UNIQUE KEY uk_order_no (order_no), KEY idx_user_created (user_id, created_at), KEY idx_shop_status (shop_id, status, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表;索引idx_shop_status是给商家后台查「待接单列表」用的idx_user_created给用户查历史订单。注意status放在联合索引第二列因为商家查询总是先过滤shop_id再按状态排序。2.3 骑手调度与配送轨迹的建模配送轨迹表rider_location是写入最猛的表骑手端每 35 秒上报一次位置。这张表不能和订单表放同一个库否则午高峰的写入会把订单查询拖死。常见做法是按天分表rider_location_20250101这种过期数据直接 drop 分区。CREATE TABLE rider_location ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, rider_id BIGINT UNSIGNED NOT NULL, order_no VARCHAR(32) DEFAULT NULL COMMENT 关联订单空闲时为空, lng DECIMAL(10,7) NOT NULL COMMENT 经度, lat DECIMAL(10,7) NOT NULL COMMENT 纬度, report_time DATETIME NOT NULL, KEY idx_rider_time (rider_id, report_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT骑手位置轨迹;经纬度用DECIMAL(10,7)而不是FLOAT因为浮点精度在距离计算时会产生几米的偏差调度算法对距离敏感。order_no允许为空因为骑手空闲时也在上报位置用于派单算法找最近的骑手。3. 订单状态机与高频写入的索引策略3.1 状态流转的数据库约束怎么加订单状态从待支付到已完成中间有取消、退款、超时未支付等分支。很多团队只在代码里控制状态流转数据库层没有任何约束结果出现「已取消订单又被接单」的脏数据。我的做法是在orders表加一个status的检查约束MySQL 8.0 支持同时在应用层用状态机引擎。-- MySQL 8.0.16 支持 CHECK 约束 ALTER TABLE orders ADD CONSTRAINT chk_status CHECK (status IN (0,1,2,3,4,5));但 CHECK 只能约束取值范围不能约束流转方向。流转方向建议用一张order_status_log表记录每次变更配合应用层状态机。这张日志表还能用于排查「订单卡在配送中不动了」这类问题。CREATE TABLE order_status_log ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL, from_status TINYINT NOT NULL, to_status TINYINT NOT NULL, operator_type TINYINT NOT NULL COMMENT 1用户 2商家 3骑手 4系统, operator_id BIGINT UNSIGNED DEFAULT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_order_no (order_no, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单状态变更日志;3.2 午高峰写入的索引优化与分表边界午高峰 11:3013:00 的订单写入量可能是平峰的 20 倍。如果orders表只有主键索引写入没问题但商家后台的「待接单」查询会走全表扫描。所以索引要精准idx_shop_status覆盖商家查询idx_user_created覆盖用户查询不要加多余的索引每个索引都会拖慢写入。分表的边界怎么定我的经验是单表超过 2000 万行或单库磁盘超过 500GB 就该考虑分表。外卖订单按shop_id哈希分 16 张表比较常见因为商家查询总是带shop_id。但用户查历史订单需要跨分片这时候可以走 ES 或单独建一张用户维度的索引表。-- 分表后的查询示例商家查待接单 SELECT order_no, total_amount, created_at FROM orders_05 WHERE shop_id 12345 AND status 1 ORDER BY created_at ASC LIMIT 20;注意ORDER BY created_at ASC让最早支付的订单排前面商家先接老单。LIMIT 20是分页但外卖场景一般不做深度分页商家接完就刷新。3.3 用覆盖索引把商家后台查询压到 5ms商家后台最频繁的查询是「待接单列表」字段固定单号、金额、下单时间、菜品摘要。如果每次都要回表查order_item响应时间会翻倍。做法是建覆盖索引把常用字段冗余到orders表。ALTER TABLE orders ADD COLUMN item_summary VARCHAR(255) COMMENT 菜品摘要如宫保鸡丁x1 米饭x1; ALTER TABLE orders ADD INDEX idx_shop_status_cover (shop_id, status, created_at, order_no, total_amount, item_summary);这样查询直接在索引里完成不用回表。item_summary在订单创建时写入长度控制在 255 以内。代价是写入时多拼一个字符串但相比查询性能提升完全值得。4. 避坑外卖数据库设计里最容易翻车的五个点4.1 用浮点数存金额导致对账差几分钱现象财务对账时发现订单总额和支付流水差 0.01 元查半天查不出原因。原因DECIMAL或FLOAT存金额累加时产生精度误差。解决所有金额字段用INT存分前端展示时除以 100。支付回调的金额也要转成分再比对。4.2 订单表没有冗余菜品快照改价后历史订单金额错乱现象商家改了菜品价格用户查看三个月前的订单金额变了。原因order_item只存dish_id查询时 joindish表取当前价格。解决order_item必须冗余dish_name、unit_price、spec_desc下单时写入永不更新。4.3 骑手轨迹表和订单表同库午高峰互相拖死现象午高峰商家刷新待接单列表转圈骑手位置上报也延迟。原因轨迹表写入量大和订单表争抢 IO 和连接数。解决轨迹表独立库或独立实例按天分表过期数据直接 drop。4.4 状态字段用字符串存索引失效还占空间现象WHERE status 已支付查询慢索引不生效。原因字符串比较比整数慢且字符集排序规则影响索引。解决状态用TINYINT应用层维护枚举映射。查询时用整数。4.5 忘记给订单号加唯一索引重复支付无法拦截现象用户重复点击支付生成两笔订单扣了两次钱。原因order_no没有唯一约束插入时不做去重。解决order_no加UNIQUE KEY支付回调时用INSERT ... ON DUPLICATE KEY UPDATE或先查后插加锁。5. 进阶用分区表把历史订单查询和在线业务隔离5.1 按 RANGE 分区实现冷热数据分离订单数据有明显的冷热特征最近 7 天的订单查询频繁3 个月前的订单几乎没人看。用 MySQL 的 RANGE 分区按created_at月份切分查询时优化器自动裁剪分区。ALTER TABLE orders PARTITION BY RANGE (TO_DAYS(created_at)) ( PARTITION p202501 VALUES LESS THAN (TO_DAYS(2025-02-01)), PARTITION p202502 VALUES LESS THAN (TO_DAYS(2025-03-01)), PARTITION p202503 VALUES LESS THAN (TO_DAYS(2025-04-01)), PARTITION p_max VALUES LESS THAN MAXVALUE );查询WHERE created_at 2025-03-01时优化器只扫p202503和p_max数据量小一个数量级。注意分区键必须包含在主键或唯一索引里否则建不了分区。5.2 用事件调度器自动归档过期订单手动 drop 分区太累用 MySQL 的EVENT定时任务每月 1 号把 6 个月前的分区数据导出到归档库然后 drop 分区。DELIMITER $$ CREATE EVENT ev_archive_orders ON SCHEDULE EVERY 1 MONTH STARTS 2025-01-01 03:00:00 DO BEGIN -- 将过期分区数据插入归档表 INSERT INTO orders_archive SELECT * FROM orders PARTITION (p202406); -- 删除过期分区 ALTER TABLE orders DROP PARTITION p202406; END$$ DELIMITER ;这个事件在业务低峰期执行orders_archive表可以放在更便宜的存储上。注意DROP PARTITION是 DDL会锁表瞬间但比DELETE快得多。5.3 验证分区裁剪是否生效建完分区后用EXPLAIN看查询是否命中分区裁剪。EXPLAIN SELECT order_no, total_amount FROM orders WHERE created_at 2025-03-15 AND created_at 2025-03-16;如果partitions列只显示p202503说明裁剪生效。如果显示所有分区检查查询条件是否用了函数包裹created_at比如DATE(created_at) 2025-03-15会导致裁剪失效。我自己的习惯是每次加分区或改索引后一定用EXPLAIN和SHOW PROFILE跑一遍典型查询确认执行计划符合预期再上线。数据库设计没有后悔药上线后再改分区键代价是停机迁移。希望帮到你。本文还有配套的精品资源点击获取