简介一份基于C#与SQL Server 2019开发的餐饮外卖销售系统数据库设计资源包面向高校数据库课程设计及桌面应用初学者完整覆盖商家、客户、骑手三类角色的操作界面与注册登录流程以扁平化视觉风格呈现界面完成度接近商业级产品。资源共46个文件压缩后约886KB主体为C#源码同时包含界面资源文件、图片素材、应用配置及可执行程序项目结构规范便于定位各模块代码。源码注释详细且逻辑通俗配置好SQL Server环境后可直接使用Visual Studio打开运行省去从零搭建的麻烦曾获数据库课设满分评价。目前已有1592人学习尤其适合需要快速完成课设、或想参考成熟商业风格UI的计算机专业学生。1. 打开这份餐饮外卖数据库设计你要先看清订单这条生命线做餐饮外卖的人每天都在算三笔账用户下了单能不能扣住库存骑手接单后订单状态会不会错乱月底对账时每一笔优惠分摊去哪了。这套数据库设计要解决的正是这三件事。它面向的不是「能存数据就行」的玩具库而是一个从用户点餐、商家接单、骑手配送、支付回调、退款售后全链路走通的业务库。如果你正在搭外卖系统或者手里拿到一份 .rar 里只有 ER 图和建表脚本的设计稿这篇笔记帮你把订单主表、明细表、库存表、状态流转串成一条线讲清楚每个字段为什么长这样以及上线后最常见的翻车点在哪。2. 从外卖业务场景反推数据模型先定实体关系再谈表结构2.1 为什么外卖系统不能直接照搬超市收银的库表外卖和传统零售在数据形态上有三个本质区别决定了表结构不能照抄。第一外卖订单是「先付款后履约」的流程订单状态不是一张订单表里的一个字段就能描述的。用户提交订单后要经过支付、商家接单、备餐、骑手取餐、送达、结算中间还穿插用户取消、商家拒单、退款。每个状态变更都涉及不同的角色和时间点如果不建状态流转记录排查纠纷时只能干瞪眼。第二外卖是典型的「多商户 多门店 多 SKU」结构。同一个用户在同一个平台上可能同时从两个店铺下单每单里又可能有加料、去冰、大份小份的组合规格。这意味着订单和商品之间绝不是「一单一行」的关系而是必须拆成订单主表 订单明细表把一次下单和商品快照分开存。第三库存是浅库存。餐饮备货是当天采购当天消耗很多菜品卖完就下架。数据库层面必须支持「扣减即锁定」的原子操作否则并发场景下很容易超卖。基于这三点建模的第一步是先画实体关系图明确哪些实体是主数据、哪些是流程数据、哪些是流水数据。2.2 实体梳理用户、店铺、菜品、订单、配送各归各位一份完整的外卖库设计核心实体至少有这样几类用户侧user用户账号、user_address收货地址、cart_item购物车商家侧shop店铺、product菜品、product_sku规格、category分类交易侧order_info订单主表、order_detail订单明细表、payment支付流水、refund_info退款单履约侧delivery配送单、status_log订单状态日志营销侧coupon优惠券、user_coupon用户券记录关系上注意几个容易画错的点user和shop都是独立的主数据不要在设计时就把店铺挂在某一个用户下。product和product_sku是父子关系同一个菜品可能有大份、小份、加辣不加辣多个 SKU价格和库存挂在 SKU 上而不是菜品上。订单主表和明细表是标准的order_info一对多order_detail关系明细表里要冗余一份商品名称、单价、规格快照——因为菜品价格随时会改订单里存的必须是下单那一刻的价。配送信息建议单独建表不要硬塞进订单主表。原因是配送单有自己的生命周期骑手接单、到店、取餐、送达每个节点要写时间戳如果都塞进订单主表字段会越来越多而且配送失败或被转单时你只需要更新配送单不影响订单本身。2.3 订单状态机从待支付到已完成哪些跳转要禁止外卖订单的状态不是「随便改」它是一台状态机。常见做法是给状态字段定义一组枚举值并在应用层或数据库层约束合法流转。一个典型的正向链路是待支付 → 已支付 → 商家已接单 → 备餐中 → 骑手已取餐 → 已送达 → 已完成分支链路包括待支付 → 已取消用户主动取消或超时关单 已支付 → 退款中 → 已退款商家未接单前用户可申请退款 商家已接单 → 拒单退款商家因缺货拒绝接单 骑手已取餐 → 配送异常 → 退款处理中建表时我建议至少留三个与状态相关的字段status当前状态、prev_status上一状态、status_version状态版本号。prev_status用于审计和回溯status_version用来做乐观锁——更新时带上WHERE status_version 上一版本防止两次并发操作把状态覆盖成脏数据。状态机的约束写在数据库里更稳妥用 CHECK 约束或触发器把「非法跳转」直接挡住。比如「待支付」不允许直接跳到「已完成」这种防呆写在应用层也能做但数据库加一层更安全尤其是团队里新人多的时候。3. 核心建表脚本order 主表、明细表与库存表的落地写法3.1 order_info 主表为什么把收货地址直接冗余进订单订单主表是一张订单的核心载体它承载的是「这一单谁买的、从哪家店、送到哪、多少钱」。一个常见的设计原则叫「下单即快照」——用户地址、店铺名、商品名这些信息在下单那一刻就固化进订单而不是通过外键去实时关联。原因很现实用户改了默认地址你不能让历史订单的收货地址跟着变店铺改了个名订单里还应该保留下单时的店名。这就是外卖订单表里到处都是冗余字段的原因。订单主表的常见字段设计如下CREATE TABLE order_info ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 物理主键, order_no VARCHAR(32) NOT NULL COMMENT 业务订单号显示给用户和回调使用, user_id BIGINT UNSIGNED NOT NULL COMMENT 下单用户ID, shop_id BIGINT UNSIGNED NOT NULL COMMENT 店铺ID, shop_name VARCHAR(64) NOT NULL COMMENT 店铺名称快照, receiver_name VARCHAR(32) NOT NULL COMMENT 收货人姓名, receiver_phone VARCHAR(20) NOT NULL COMMENT 收货人手机号, receiver_address VARCHAR(255) NOT NULL COMMENT 完整收货地址快照, total_amount DECIMAL(10,2) NOT NULL COMMENT 订单原价总额, discount_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 优惠总额优惠券活动, pay_amount DECIMAL(10,2) NOT NULL COMMENT 实付金额, status TINYINT NOT NULL DEFAULT 0 COMMENT 订单状态0待支付 1已支付 2已接单 3配送中 4已送达 5已完成 6已取消 7退款中 8已退款, prev_status TINYINT NOT NULL DEFAULT 0 COMMENT 上一状态用于审计和回滚, status_version INT UNSIGNED NOT NULL DEFAULT 1 COMMENT 状态版本号乐观锁用, remark VARCHAR(255) NULL COMMENT 用户备注, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 逻辑删除标记0正常 1已删除, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 下单时间, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 最后更新时间 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT外卖订单主表;注意几个关键点order_no和id是两回事。id是自增物理主键只在系统内部用order_no是业务单号要唯一要生成规则可读比如日期 随机串用户和支付回调都认这个号。两张表关联用id对外暴露用order_no避免用户猜出你的单量。我给order_no建唯一索引既保唯一也给回调查询走索引。金额字段全部用DECIMAL(10,2)绝对不用FLOAT或DOUBLE。二进制浮点计算会产生精度误差对账时差一分钱都说不清。整数场景下你可以用「分」存储但表设计里DECIMAL更直观代码里再统一转分计算。receiver_name、receiver_phone、receiver_address整段冗余到订单主表包括shop_name。后面查订单、导出报表、打印小票时不需要再去关联用户地址表和店铺表联表少了查询快了数据还有历史保留价值。3.2 order_detail 明细表一次点餐可能拆成多行快照明细表记录的是「这一单具体买了哪些菜」。为什么不能直接用一个字段把商品名拼成字符串塞进主表因为你要算销量排行、要看某个菜品的复购率、要对账每个菜品实付金额——拆开存储才能统计。CREATE TABLE order_detail ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 物理主键, order_no VARCHAR(32) NOT NULL COMMENT 业务订单号关联order_info, order_id BIGINT UNSIGNED NOT NULL COMMENT 订单主表ID, product_id BIGINT UNSIGNED NOT NULL COMMENT 菜品ID, sku_id BIGINT UNSIGNED NOT NULL COMMENT 规格ID, product_name VARCHAR(128) NOT NULL COMMENT 菜品名称快照, sku_spec VARCHAR(64) NOT NULL COMMENT 规格描述快照如大份/加冰/去辣, price DECIMAL(10,2) NOT NULL COMMENT 下单时单价, quantity INT NOT NULL DEFAULT 1 COMMENT 购买数量, item_total_amount DECIMAL(10,2) NOT NULL COMMENT 该明细原价小计, item_discount_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 该明细分摊优惠, item_pay_amount DECIMAL(10,2) NOT NULL COMMENT 该明细实付小计, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT外卖订单明细表;明细表里有个实际场景必须处理同一道菜加了两份能不能两行合并成一行我建议保留quantity字段合并成一行用数量表达。好处是统计销量时直接SUM(quantity)不会因为拆行导致同一商品多条记录。但如果是「加料」这种 SKU 级别的差异即使菜名一样只要规格不同就是不同 SKU必须拆行。还有一个设计细节product_name和sku_spec一定要做快照。菜品可能改名字、SKU 可能下架但历史订单里的记录不能跟着变。对账、开发票、售后处理时拿到的都是下单那一刻的信息这一点和主表冗余地址是同一个原则。3.3 菜品 SKU 与库存扣减乐观锁字段不能省菜的规格挂在product_sku上价格和库存都跟 SKU 走。菜品本身只存基础信息比如名字、分类、图片SKU 存具体售价和库存量。一个「鱼香肉丝」可以拆成「大份 28」「小份 18」两个 SKU。CREATE TABLE product_sku ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 规格ID, product_id BIGINT UNSIGNED NOT NULL COMMENT 菜品ID, sku_name VARCHAR(64) NOT NULL COMMENT 规格名称, price DECIMAL(10,2) NOT NULL COMMENT 当前售价, stock INT UNSIGNED NOT NULL DEFAULT 0 COMMENT 实时库存0表示售罄, status TINYINT NOT NULL DEFAULT 1 COMMENT 状态1上架 0下架, version INT UNSIGNED NOT NULL DEFAULT 1 COMMENT 乐观锁版本号, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT菜品规格表;库存扣减是关键操作这句 SQL 的写法直接决定会不会超卖。我一般推荐三种方案按场景选第一种是「乐观锁 条件更新」UPDATE product_sku SET stock stock - 1, version version 1 WHERE id #{skuId} AND stock 0 AND version #{expectedVersion};stock 0这个条件把扣减和校验合并到一条语句里数据库行锁保证同一时刻只有一个事务能改到这一行。version #{expectedVersion}是乐观锁的兜底防止 ABA 问题。这条语句影响行数为 1 说明扣减成功为 0 说明库存不足或者版本过期需要重新查库存再提示用户「已售罄」。第二种是「预占库存」模式下单时先冻结库存支付成功后正式扣减超时未支付自动释放。这种适合高峰期秒杀或者营销活动但实现复杂度高订单表里要加一个lock_stock字段对应库存冻结状态。第三种是直接依赖 Redis 扣库存再异步落库库表只是最终一致性的落点。这个适合大并发场景但对中小外卖系统来说引入额外组件前期没必要。外卖场景下我建议先做第一种简单直接等日订单量到了需要做活动秒杀再演进到第二种。表结构里提前把version字段留好迁移不伤筋动骨。4. 外卖库最容易翻车的 5 个细节并发、幂等和金额精度4.1 超卖库存扣减只查再改订单量一大就出事现象促销时段某个菜品卖出了 200 份实际备货只有 100 份。原因库存扣减写成「先SELECT stock然后在 Java 里判断stock 0再UPDATE stock stock - 1」。两个请求同时查到了stock 1都判断通过各自执行 UPDATE把库存扣成了负数。解决把判断和扣减合并成一条 SQL用UPDATE ... WHERE stock 0加乐观锁。SQL 影响行数为 0 就说明这次没抢到直接返回售罄。数据库行锁保证同一行在同一时刻只能有一个事务在改。4.2 支付回调被重试 n 次幂等表没建就等着数据重复现象用户支付成功支付回调因为网络抖动重试了三次订单状态被更新了三次流水表里产生了三条重复的支付记录。原因支付渠道的回调天然会重试而回调处理逻辑里没有做去重。解决建一张payment_notify流水表给order_no加唯一索引。每次回调进来先INSERT IGNORE写一条记录影响行数为 1 才继续处理状态更新为 0 说明这条回调已经处理过直接返回成功。状态更新本身也要带上条件WHERE status 0保证只有待支付状态的订单能被支付回调改成已支付。4.3 优惠分摊去尾差对不上账基本都是这里出的现象订单整单优惠了 5 元明细里有三道菜每道菜按比例分摊三个分摊金额相加和 5 元差了 0.01 元。月底对账差一分钱查半天查不出原因。原因金额分摊按比例计算时每一行都四舍五入尾差累积起来就丢了。比如 10 元优惠按 7:3 分一行 6.99一行 2.99加到一起是 9.98少了 0.02。所有明细分摊金额必须严格等于整单优惠金额。解决分摊时用「逐行四舍五入最后一行兜底」的算法——前面的行正常舍入计算最后一行的分摊金额等于整单优惠金额减前面所有行分摊金额之和把尾差放到最后一行。建表时明细表里的item_discount_amount和主表的discount_amount保持可校验关系对账 SQL 直接查偏差SELECT order_no FROM order_info o WHERE o.discount_amount 0 AND o.discount_amount ( SELECT IFNULL(SUM(item_discount_amount), 0) FROM order_detail d WHERE d.order_id o.id );查出来不为空说明分摊逻辑有 bug这条 SQL 放进每周巡检脚本里。4.4 订单状态被直接 UPDATE缺少流转约束的代价现象运营手动改数据库把一笔「已退款」的订单改回「已完成」然后财务导出报表时发现这笔订单既算收入又算退款两边账不平。原因状态字段没有流转约束谁都能直接改而且改的时候不写日志。解决建状态日志表order_status_log每一次状态变更都插入一条记录order_id、from_status、to_status、operator_typeuser/system/shop/rider、operator_id、create_time。数据库层可以加 CHECK 约束限制状态值范围合法的状态跳转放应用层做校验但日志表必须无条件写。谁在什么时间把订单从什么状态改到什么状态每一步都有据可查这是处理客诉和财务审计的救命稻草。4.5 物理删除和逻辑删除混用数据越查越少现象一个取消的订单被物理 DELETE 后用户端订单列表历史突然少了一单且运营想分析取消原因时数据已经不在了。原因有些开发图省事直接 DELETE有些按逻辑删除标记走。两种策略混用导致同一条数据在不同接口里行为不一致。解决所有业务表统一使用deleted字段做逻辑删除禁止物理 DELETE。查询时处处带deleted 0条件虽然写 SQL 时啰嗦一点但历史数据永远留得住。真正要清理数据时走定时任务归档到历史库而不是直接删线上表。外卖行业的售后纠纷最长可能追溯好几个月一条订单记录删了就再也回不来了。5. 查询慢了不要先怪服务器外卖库索引与分页的调法5.1 组合索引顺序user_id 和 shop_id 谁放前面差别很大订单表的查询场景基本集中在三块用户查自己的历史订单、商家查店铺的实时订单、运营查某个时间段的全平台订单。对应三个高频查询条件组合-- 场景一用户端「我的订单」 WHERE user_id ? AND status IN (0,1,2,3,4,5) ORDER BY create_time DESC -- 场景二商家端「接单列表」 WHERE shop_id ? AND status IN (1,2) ORDER BY create_time ASC -- 场景三运营端「按时间范围拉订单」 WHERE create_time BETWEEN ? AND ? AND shop_id ?索引设计要按「等值条件放前面范围条件放后面」的原则建。场景一是典型的等值 排序建(user_id, create_time)组合索引user_id精确过滤后create_time直接走索引排序不用额外 filesort。场景二建(shop_id, status, create_time)商家一般同时挂几十个活跃订单status过滤到一两个值后数据量已经很小排序成本可控。注意status IN (...)会让组合索引里status后面的字段失效。所以设计索引顺序时把status放中间而不是最后。MySQL 8 支持索引跳跃扫描但依赖它不如把索引建对来得稳妥。索引不是越多越好订单表高频写。每多一个索引INSERT 和 UPDATE 都要同步维护。外卖订单表最多建 4 5 个索引切不可为了一个低频报表查询单独建一个全表人物的组合索引。低频查询宁可走定时任务汇总也不要在线上库压写性能。5.2 深分页扫库拖垮库用时间戳游标代替 offset订单列表的经典分页 SQL 是SELECT id, order_no, pay_amount, status FROM order_info WHERE user_id ? ORDER BY create_time DESC LIMIT 10 OFFSET 20000;数据量到了一定规模后OFFSET会越来越大MySQL 要扫过前面 20000 行再丢掉才能返回 10 行查询越来越慢。替代方案是游标分页利用上次查询结果里最后一条记录的create_time作为下一次查询的起点。SELECT id, order_no, pay_amount, status FROM order_info WHERE user_id ? AND create_time #{lastCreateTime} ORDER BY create_time DESC LIMIT 10;create_time上的(user_id, create_time)索引会直接命中避免了大偏移量的扫描。实现时注意边界问题如果同一秒内有多条订单create_time #{lastCreateTime}可能会漏数据。解决办法是在查询时把主键也带进游标条件create_time #{lastCreateTime} OR (create_time #{lastCreateTime} AND id #{lastId})。第一次查询不用带id条件翻页后把上一条记录的create_time和id都带上。前端展示上有个好处游标分页天然适合「加载更多」模式用户往下拉就带上一次查询的最后一条订单时间戳继续加载不再需要页码跳转体验也更顺滑。5.3 历史订单归档与分表策略外卖订单有明显的冷热分层。用户大部分时间只看最近三个月的订单运营也只分析最近的数据。半年以前的订单基本只有司法和财务场景才用得上。常见的做法是「按时间归档 按用户分表」。订单主表和明细表以月度为单位归档到历史库线上库只保留最近 3 6 个月的数据历史数据放归档表或者冷存储。查询端做路由最近 3 个月走在线库更早的走归档查询服务或者干脆提示用户去 App 下载历史账单。订单表量大的时候可以按user_id哈希分表。分表后所有按用户维度进行的查询都路由到同一张物理表商家端查店铺订单时用shop_id冗余一份索引表或者送到搜索组件。分表方案在日订单量达到几十万级再上前期用单库加索引完全够用。分表的代价是跨表查询和统计报表复杂度上升所以这个决策要压在业务量后面不要提前优化。6. 用一份验收清单把设计从「能跑」调到「能交付」拿到这套数据库设计动手写代码之前先花一天做验收能省后面三周的返工。第一校验金额关系。跑一遍那条「整单优惠金额等于明细分摊之和」的 SQL然后把total_amount discount_amount pay_amount也加进去检查。金额关系是订单库的生命线错一处所有财务统计全部失信。第二验证状态机跳转。写一个小的 Python 脚本模拟所有状态跳转路径把合法跳转和不合法跳转各跑一遍确认数据库层和应用层都能挡住非法更新。重点测「待支付直接到已完成」「退款完成后还能改回已支付」这两条最容易被绕过路径。第三压一次并发扣库存。用 50 个并发线程同时对同一个 SKU 扣减库存验证最终扣减量不超过库存总数。不要用生产环境拿测试库跑观察是否有超卖记录产生。第四做一次备份恢复演练。导出建表脚本和执行计划确认所有表都用 InnoDB都有主键都带deleted和create_time、update_time字段——这三个是所有业务表的底座。这套设计里我把用户地址、店铺名称、商品规格全部做快照冗余上线后你自然会尝到甜头——打印小票、对接发票、客服查单都不用到处联表。归档脚本和巡检 SQL 也要在第一个版本就建好不要等数据量大了再补那时候补起来全是眼泪。希望帮到你。本文还有配套的精品资源点击获取