企业官网建设流程全解析

简介：以餐饮外卖为主题、基于C#与SQL Server 2019的销售系统数据库设计包，面向高校数据库课程设计及C#桌面应用开发者。项目包含商家、客户、骑手三类角色界面与注册界面，采用扁平化设计，视觉与交互达到商业软件级，曾获数据库课设满分评价。压缩包共46个文件，整体约886KB，文件类型涵盖13个存放业务逻辑的C#源码文件、界面布局资源、编译缓存、资源映射、界面图片、应用配置、可执行程序、调试符号、解决方案及说明文档，目录按模块划分，在Visual Studio中配置好环境后可直接打开运行。代码注释详细，适合理解登录、注册及各角色窗体的界面设计逻辑，以及外卖订单、商家信息、用户信息等核心数据表结构，还有C#程序访问SQL Server数据库的完整流程。已有1592人学习，可作为数据库课设参考或同类型管理系统开发起点。

1. 餐饮外卖销售系统数据库设计：为什么说表结构决定外卖系统的生死

很多从单体应用起步的外卖项目，代码写得挺整齐，一到数据库层面就露怯：订单表把用户信息、商家信息、菜品快照全塞在同一张宽表里，优惠金额用 FLOAT 存，配送状态用随手写的字符串标记。等到订单量破万，慢查询、死锁、对账不平接踵而至，才意识到餐饮外卖销售系统数据库设计在第一天就没站稳。数据库设计的核心目标是三件事：把业务实体正确拆分、让常用查询走得快、让资金相关的数据经得起审计。这篇实战笔记会从实体梳理、建表 DDL、事务与并发控制讲到最常见的踩坑点，所有脚本都是 MySQL 8.0 可直接执行的，适合做课程设计或小规模外卖系统初版。

2. 先建模再写码：外卖系统的实体识别与关系梳理

在写任何 CREATE TABLE 之前，我习惯先花半天时间把业务里会出现的关键名词列在纸上，逐个画关系。这不是走流程，而是因为外卖系统的表数量虽然不算多，但表之间的边界特别容易搞错：用户和收货地址是一对多，商家和菜品是一对多，菜品和规格是一对多，订单和订单明细是一对多，订单和配送是一对一。这些关系一旦画错，后面加字段、改索引全是牵一发动全身的事。

2.1 实体清单与关系边界：用户、商家、菜品、订单、配送谁跟谁是一对多

一套最小可用的外卖系统，我一般会拆出八张核心业务表：用户表、商家表、菜品表、菜品规格表（SKU）、订单主表、订单明细表、配送表、收货地址表。可选但推荐加的还有购物车表、优惠券表、菜品分类表。下表是我常用的实体划分方式：

先说最容易被忽视的关系：用户和收货地址。一个用户在家里点一次、在公司点一次，地址必须能存多条，所以地址要单独建表，user_id 指向用户。同时，订单表里存的 delivery_address 是下单那一刻的地址快照，不是实时去地址表里外键引用。为什么？因为用户事后改了地址簿里的地址，历史订单里的配送地址不应该跟着变。

再看商家和菜品。商家表存店铺维度的固定信息：店名、电话、坐标、营业状态。菜品表存菜品维度的信息：名称、描述、图片、上下架状态。一个商家有几十上百个菜品，所以 merchant_id 在菜品表里是普通索引，不是唯一索引。

菜品和规格这对关系是新手最容易漏的。同一个"农家小炒肉"，大份 32、小份 22，这在数据库里不是两条菜品记录，而是一条菜品记录挂两条 SKU 记录。菜品表管"这是什么菜"，SKU 表管"这个菜有哪些卖法、各自多少钱、还剩多少库存"。菜品表里不存价格，价格永远在 SKU 表上。

订单和订单明细的一对多关系是所有设计的核心。一次下单点了三个菜，订单主表只存一条记录，记录这笔订单的总额、支付金额、配送信息、状态；三个菜分别变成订单明细表的三行，每行记录一道菜当时的名称、单价、数量、小计。主表和明细表通过 order_id 关联。后面要统计"今天卖了多少份青椒肉丝"，直接 group by dish_id 扫明细表就行，不用碰订单主表。

配送和订单的关系是一对一。一笔订单只会有一条配送记录，配送表用 order_id 做唯一索引来保证。骑手接单、取餐、送达这些过程状态放在配送表里，哪怕订单本身的状态还没更新，运营人员也能看到配送环节卡在哪一步。表和表之间的边界先理清，后面的 DDL 才能定得下来。

2.2 快照字段与冗余字段：订单明细为什么必须存下单时的名称、单价和图片

这是一个很多人会犯迷糊的设计点：订单明细表里，除了 dish_id 这个关联字段，我建议把 dish_name、sku_name、price、dish_image 这四个字段全部冗余出来。初看这违背了"减少冗余"的规范化直觉，但在外卖业务里这是必须的。

菜品表是随时可能变的。商家把"农家小炒肉"改名为"农家炒肉"，或者把价格从 32 调到 38，如果订单明细只存 dish_id，那么半年前的订单查出来就显示成今天的菜名和价格，跟用户当时付的钱对不上。外卖订单明细本质是一张商业凭证，它必须还原下单那一刻的真实情况，所以名称、单价、图片这些会被修改的字段，全部要快照进明细表。

冗余字段带来的代价是写入时要多写几个字段，好处是查询时不用为了拿菜品名称和价格去联菜品表，对账和报表反而更快。我在实际项目里的取舍标准就一句话：会被频繁修改的展示字段，如果和历史订单强相关，就冗余进明细表；不会被修改的纯业务主键，比如 user_id、merchant_id，留在主表即可。

那菜品表和 SKU 表里的价格字段还要不要？要。SKU 表里的 price 是"当前售价"，供菜单页展示和下单初始化价格用；订单明细里的 price 是"下单时售价"，是历史的定格。两边各管各的，互不覆盖。这也是外卖数据库设计和普通进销存系统最大的不同：进销存关心当前库存和价格，外卖还额外关心每一笔历史交易的时间切片。

3. 建表落地：用户、商家、菜品三大基础表的 DDL 与索引选择

实体关系理清楚之后，我才会开始写建表脚本。建表顺序也讲究：先建不依赖别人的基础表，再建订单这类引用别人的核心表。这样即便开了外键约束，导入数据时也不会被顺序卡脖子。

3.1 用户表与商家表：字段类型、唯一索引与状态位的设计细节

先看用户表。外卖用户的核心标识是手机号，自建账号体系时手机号必须加唯一索引；如果接第三方登录，可以把 openid 也纳入唯一索引。下面这份 DDL 是我在 MySQL 8.0 上的常用写法：

CREATE TABLE sys_user ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '用户ID', phone VARCHAR(20) NOT NULL COMMENT '手机号（唯一）', password_hash VARCHAR(64) NOT NULL COMMENT '密码哈希', nickname VARCHAR(50) DEFAULT NULL COMMENT '昵称', avatar_url VARCHAR(255) DEFAULT NULL COMMENT '头像地址', gender TINYINT NOT NULL DEFAULT 0 COMMENT '性别：0未知 1男 2女', status TINYINT NOT NULL DEFAULT 1 COMMENT '账号状态：0禁用 1正常', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (id), UNIQUE KEY uk_phone (phone), KEY idx_status (status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='用户表';

id 用 BIGINT UNSIGNED 而不是 INT，是因为外卖平台一旦做营销活动，用户量增长可能远超 INT 上限，线上换主键类型是极痛的操作。phone 用 VARCHAR(20) 而不是 CHAR(11)，顺便兼容带区号的国际号码。password_hash 只存哈希不存明文，长度 64，正好容纳 SHA-256 的十六进制输出。gender 和 status 都用 TINYINT 而不用 VARCHAR，值的语义由代码层控制，数据库只认数字，过滤效率更高。created_at 和 updated_at 全部交给数据库默认值，updated_at 用 ON UPDATE CURRENT_TIMESTAMP 可以自动记录每次修改时间。

索引方面，uk_phone 是登录注册的准入索引，必须存在。idx_status 用于后台做账号禁用类低频查询，单列已经够用。注意我没有给 nickname 建索引，因为昵称只做展示不做搜索，加索引反而增加写放大。

商家表的 DDL 我会这样写：

CREATE TABLE merchant ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '商家ID', name VARCHAR(100) NOT NULL COMMENT '商家名称', logo_url VARCHAR(255) DEFAULT NULL COMMENT 'Logo地址', category VARCHAR(50) DEFAULT NULL COMMENT '主营分类：快餐/川菜/奶茶等', contact_phone VARCHAR(20) NOT NULL COMMENT '联系电话', address VARCHAR(255) NOT NULL COMMENT '商家地址', longitude DECIMAL(10, 6) DEFAULT NULL COMMENT '经度', latitude DECIMAL(10, 6) DEFAULT NULL COMMENT '纬度', status TINYINT NOT NULL DEFAULT 1 COMMENT '营业状态：0打烊 1营业', rating DECIMAL(3, 2) NOT NULL DEFAULT 5.00 COMMENT '评分', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (id), KEY idx_category (category), KEY idx_status_rating (status, rating) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='商家表';

经纬度用 DECIMAL(10, 6)，是因为经纬度虽然是浮点数，但算距离时对精度有硬要求，DECIMAL 精确到小数点后 6 位，换算成米级精度足够。rating 用 DECIMAL(3, 2) 而不是 FLOAT，避免浮点误差在排行榜排序时产生诡异并列。idx_status_rating 是复合索引，对应外卖 App 首页"附近营业中评分最高"这个高频查询。复合索引的顺序有讲究：先放 status 做等值过滤，再放 rating 排序，这样索引能直接覆盖"营业中 + 按评分排序"，不需要额外 filesort。

3.2 菜品表与 SKU 表：SPU/SKU 两级拆分与库存字段设计

菜品表的 DDL：

CREATE TABLE dish ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '菜品ID', merchant_id BIGINT UNSIGNED NOT NULL COMMENT '所属商家ID', name VARCHAR(100) NOT NULL COMMENT '菜品名称', description VARCHAR(500) DEFAULT NULL COMMENT '菜品描述', main_image_url VARCHAR(255) DEFAULT NULL COMMENT '主图URL', category_id BIGINT UNSIGNED DEFAULT NULL COMMENT '菜品分类ID', status TINYINT NOT NULL DEFAULT 1 COMMENT '上下架状态：0下架 1上架', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (id), KEY idx_merchant_category (merchant_id, category_id), KEY idx_merchant_status (merchant_id, status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='菜品表';

菜品表不直接存价格，价格在 SKU 表上，因为一个菜有多档规格。idx_merchant_category 支撑商家后台按分类浏览菜品，idx_merchant_status 支撑前台"查看某商家上架的菜品"。两个复合索引都以 merchant_id 打头，因为菜品的查询必然带商家维度，去掉 merchant_id 这两条索引基本发挥不了作用。

接下来是 SKU 表，也叫菜品规格表：

CREATE TABLE dish_sku ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'SKU ID', dish_id BIGINT UNSIGNED NOT NULL COMMENT '所属菜品ID', name VARCHAR(50) NOT NULL COMMENT '规格名称：大份/小份/冰/去冰', price DECIMAL(10, 2) NOT NULL COMMENT '实时售价', original_price DECIMAL(10, 2) DEFAULT NULL COMMENT '划线原价', stock INT NOT NULL DEFAULT 0 COMMENT '库存', sales_count INT NOT NULL DEFAULT 0 COMMENT '累计销量', status TINYINT NOT NULL DEFAULT 1 COMMENT '售卖状态：0停售 1售卖', PRIMARY KEY (id), KEY idx_dish (dish_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='菜品SKU表';

stock 字段有个实战细节：库存扣减不要应用层先 SELECT 再判断再 UPDATE，而是用一条带条件的 UPDATE 语句原子完成。比如UPDATE dish_sku SET stock = stock - 1 WHERE id = 1001 AND stock >= 1，通过 affected_rows 是否等于 1 判断是否超卖。sales_count 是冗余字段，用来在列表页显示"月售 xxx"而不必实时聚合订单明细，代价是要在订单完成时由程序更新，或者夜间用定时任务重算，这是典型拿空间换查询性能。如果你的系统只允许同一菜品下只有一个默认规格，也可以直接给 dish_id 建唯一索引，具体看业务复杂度。

4. 订单链路核心表：订单主表、订单明细与配送表的完整 DDL

基础表搭好后，核心的订单链路才是外卖数据库设计真正见功夫的地方。订单主表、订单明细表、配送表三张表的字段设计，直接决定了对账、配送跟踪和数据分析能不能跑得顺。

4.1 订单主表与订单明细表：字段语义、状态枚举与复合索引落位

订单主表的 DDL：

CREATE TABLE order_master ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '订单ID', order_no VARCHAR(32) NOT NULL COMMENT '业务订单号', user_id BIGINT UNSIGNED NOT NULL COMMENT '下单用户ID', merchant_id BIGINT UNSIGNED NOT NULL COMMENT '商家ID', total_amount DECIMAL(12, 2) NOT NULL COMMENT '订单总金额（菜价合计）', discount_amount DECIMAL(12, 2) NOT NULL DEFAULT 0.00 COMMENT '优惠金额', pay_amount DECIMAL(12, 2) NOT NULL COMMENT '实付金额 = 总金额 - 优惠', status TINYINT NOT NULL DEFAULT 0 COMMENT '订单状态：0待支付 1已支付 2制作中 3配送中 4已送达 5已取消', payment_method TINYINT DEFAULT NULL COMMENT '支付方式：1余额 2微信 3支付宝', delivery_address VARCHAR(255) NOT NULL COMMENT '配送地址快照', delivery_lng DECIMAL(10, 6) DEFAULT NULL COMMENT '配送地址经度', delivery_lat DECIMAL(10, 6) DEFAULT NULL COMMENT '配送地址纬度', rider_id BIGINT UNSIGNED DEFAULT NULL COMMENT '接单骑手ID', remark VARCHAR(255) DEFAULT NULL COMMENT '用户备注', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '下单时间', paid_at DATETIME DEFAULT NULL COMMENT '支付时间', delivered_at DATETIME DEFAULT NULL COMMENT '送达时间', PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_status_time (user_id, status, created_at), KEY idx_merchant_status_time (merchant_id, status, created_at), KEY idx_rider_status (rider_id, status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='订单主表';

order_no 和主键 id 是两回事。业务订单号对外可见，需要防猜测、保证唯一，用唯一索引约束；id 是 InnoDB 聚簇索引用的内部主键。金额字段全部 DECIMAL(12, 2)，覆盖单笔订单最高 9999999999.99 元，对餐饮外卖足够了。status 用 TINYINT 加注释定义枚举，实际项目里建议在代码层用常量类对应，避免业务加状态时到处改 SQL。支付时间、送达时间不设默认值，只在事件发生时写入，这样才可以用WHERE paid_at IS NOT NULL过滤已支付订单。

重点讲索引。idx_user_status_time 字段顺序是 user_id、status、created_at，对应"某个用户查看订单列表并按时间倒序"的高频查询。idx_merchant_status_time 对应"商家后台处理某状态订单并按时间排序"。idx_rider_status 对应骑手端"待接单/配送中"的列表。三条复合索引的共同点是：等值条件字段放最左，排序字段放末尾。如果缺了这三条索引，订单表过十万行后，这些列表查询就会开始走全表扫描加 filesort。

订单明细表 DDL：

CREATE TABLE order_item ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '明细ID', order_id BIGINT UNSIGNED NOT NULL COMMENT '订单ID', dish_id BIGINT UNSIGNED NOT NULL COMMENT '菜品ID', sku_id BIGINT UNSIGNED NOT NULL COMMENT 'SKU ID', dish_name VARCHAR(100) NOT NULL COMMENT '下单时菜品名称（快照）', sku_name VARCHAR(50) DEFAULT NULL COMMENT '下单时SKU名称（快照）', dish_image VARCHAR(255) DEFAULT NULL COMMENT '下单时菜品图片（快照）', price DECIMAL(10, 2) NOT NULL COMMENT '下单时单价（快照）', quantity INT NOT NULL DEFAULT 1 COMMENT '数量', subtotal DECIMAL(12, 2) NOT NULL COMMENT '小计 = 单价 × 数量', PRIMARY KEY (id), KEY idx_order (order_id), KEY idx_dish (dish_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='订单明细表';

明细表的关键是快照字段。dish_name、sku_name、price、dish_image 这四个字段在下单那一刻从菜品表带过来，之后菜品改名称、改价格、换图都不影响历史订单。明细表不存 user_id 和 merchant_id，通过 order_id 关联到订单主表就能拿到，明细表保持只依赖订单主表这一条路径。idx_dish 用支撑"某道菜卖了多少份"的统计，最常见的聚合查询就是SELECT dish_id, COUNT(*), SUM(quantity) FROM order_item GROUP BY dish_id。

4.2 配送表单独建：状态字段为什么放在配送表而不是订单表

配送表的 DDL：

CREATE TABLE delivery ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '配送单ID', order_id BIGINT UNSIGNED NOT NULL COMMENT '订单ID（唯一）', rider_id BIGINT UNSIGNED DEFAULT NULL COMMENT '骑手ID', status TINYINT NOT NULL DEFAULT 0 COMMENT '配送状态：0待接单 1已接单 2取件中 3配送中 4已送达 5异常', pickup_time DATETIME DEFAULT NULL COMMENT '取件时间', deliver_time DATETIME DEFAULT NULL COMMENT '送达时间', start_lng DECIMAL(10, 6) DEFAULT NULL COMMENT '取货经度', start_lat DECIMAL(10, 6) DEFAULT NULL COMMENT '取货纬度', end_lng DECIMAL(10, 6) DEFAULT NULL COMMENT '送货经度', end_lat DECIMAL(10, 6) DEFAULT NULL COMMENT '送货纬度', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (id), UNIQUE KEY uk_order_id (order_id), KEY idx_rider_status (rider_id, status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='配送表';

这里一定会有人问：订单主表已经有 status 和 rider_id 了，为什么还要单独的配送表？因为两个状态的生命周期不同。订单状态面向用户，只关心"待支付、已支付、制作中、配送中、已送达、已取消"这六个大字；配送状态面向运营和骑手，需要更细的"已接单、取件中、配送中、异常、转单"这类颗粒度。把两套状态都塞进订单主表，会导致状态枚举膨胀、业务判断复杂。我的做法是订单主表只保留用户可见的大状态，配送表跑细粒度配送状态，两表通过 order_id 一对一关联。订单状态从"已支付"流转到"配送中"的时机，以配送表发生"骑手接单"事件为准，由应用层在同一个事务里同步更新两边状态，数据库层面不做冗余判断。

注意：uk_order_id 唯一索引是必须的，它从数据库层面保证一笔订单不可能出现两条配送记录，避免并发调用时配送单重复创建。

4.3 创建订单的事务顺序：先扣库存还是先写订单，为什么顺序错了会死锁

下单接口的事务顺序是必须较真的。我见过很多因为顺序不统一导致的死锁，尤其在商家做满减活动时，两个用户同时抢同一份库存，死锁一多，订单系统就大量超时。我的标准事务顺序是：先扣库存，再写订单。

START TRANSACTION; -- 1. 按固定顺序扣减每个 SKU 的库存，必须带 stock >= 1 条件 UPDATE dish_sku SET stock = stock - 1 WHERE id = 1001 AND stock >= 1; UPDATE dish_sku SET stock = stock - 1 WHERE id = 1002 AND stock >= 1; -- 2. 创建订单主表记录 INSERT INTO order_master (order_no, user_id, merchant_id, total_amount, discount_amount, pay_amount, status, delivery_address) VALUES ('20250601001', 10001, 2001, 74.00, 6.00, 68.00, 0, 'XX市XX区XX路XX号'); -- 3. 创建订单明细记录 INSERT INTO order_item (order_id, dish_id, sku_id, dish_name, sku_name, price, quantity, subtotal) VALUES (LAST_INSERT_ID(), 3001, 1001, '农家小炒肉', '大份', 42.00, 1, 42.00), (LAST_INSERT_ID(), 3002, 1002, '米饭', '中份', 3.00, 1, 3.00); COMMIT;

这里有三条硬性规则。第一条，扣库存的 UPDATE 必须带AND stock >= 1，通过 affected_rows 判断库存是否充足，为 0 就回滚事务，避免先 SELECT 后 UPDATE 造成超卖竞态。第二条，同一笔订单里的多个 SKU 更新永远按 SKU id 从小到大执行，所有事务都遵循同一顺序，就不会出现事务 A 锁了 1001 等 1002、事务 B 锁了 1002 等 1001 的互相等待。第三条，INSERT order_item 用 LAST_INSERT_ID() 拿刚写入的 order_id，不要应用层手工传一个可能冲突的值。

这段事务看着简单，但我在真实项目里看到最多的翻车现场是：开发图省事把扣库存放在最后，结果订单和明细都写完了，库存扣减失败，回滚一大片，而且高并发下死锁概率明显更高。所以这个顺序值得一上线就定死，写进团队开发规范。

5. 避坑：外卖数据库设计里最常见的 5 个翻车现场

这一章我把这些年在外卖数据库设计里踩过的坑按"现象 → 原因 → 解决"的格式写出来。每一条都是线上真实出现过的问题，不是教科书里的标准答案。

5.1 订单金额用 FLOAT 存，对账怎么都对不平

现象：订单表和明细表的金额字段用 FLOAT 或 DOUBLE 存储。运营每个月对账，发现系统里 SUM(pay_amount) 算出来的营业额和支付渠道结算单永远差几毛甚至几块。单看每笔订单又看不出问题，误差在小数点后第二位，只有加总时才暴露。

原因：FLOAT 和 DOUBLE 是二进制浮点数，不能精确表示所有十进制小数。0.1 + 0.2 在二进制里是个无限循环小数，累加次数多了误差被逐步放大。金额字段一旦参与单价乘数量和 SUM 聚合，误差避无可避。

解决：金额字段一律 DECIMAL。订单金额 DECIMAL(12, 2)，单价 DECIMAL(10, 2)。DECIMAL 以十进制字符串形式存储，加减乘除和 SUM 聚合都不会产生浮点误差。这个坑在开发阶段完全无感，因为数据量小误差不明显，等上线后对不上账再反查 SQL，成本就高了。还有一条隐性规则：ORM 里 DECIMAL 字段别映射成 float/double 类型，Java 用 BigDecimal，Python 用 Decimal，映射错了一样会丢精度。

5.2 表名直接用 order，建表时被 MySQL 报语法错误

现象：创建订单表用CREATE TABLE order (...)，MySQL 直接报语法错误。有人图省事用反引号包成order建表，代码里到处是SELECT * FROM \order``，在 MyBatis XML 里写动态 SQL 时反引号和 #{} 混在一起，解析经常出问题。

原因：order 是 MySQL 保留字，用于 ORDER BY，直接用作表名和列名会触发语法解析冲突。

解决：订单主表命名用 order_master 或 orders，订单明细用 order_item，从根上避开保留字。不要试图用反引号去规避，因为 SQL 里到处都有 order 字样，很容易混。同类坑位还有 level、desc、condition、key，命名时能绕就绕，尤其 desc，既是保留字又跟 desc 排序缩写撞名，我见过有人建列名叫 desc 结果 ORDER BY desc 直接写不下去。

5.3 只建了主键索引，订单列表查询慢到让用户怀疑系统坏了

现象：用户端"我的订单"页面打开需要 3 秒以上，商家端待处理订单列表加载时数据库 CPU 飙到 100%。EXPLAIN 一看 type 是 ALL，扫描行数等于全表行数，Extra 里还有 Using filesort。

原因：订单表只有主键索引。查询条件是WHERE user_id = ? ORDER BY created_at DESC，user_id 上没有索引，MySQL 只能全表扫描后做 filesort。订单量突破十万行后，这个查询的代价直线上升。用 EXPLAIN 对比一下就很直观：

-- 低效查询计划：type=ALL，rows 等于全表行数 EXPLAIN SELECT id, order_no, pay_amount, status FROM order_master WHERE user_id = 10001 ORDER BY created_at DESC LIMIT 10; -- 加了 idx_user_status_time 后：type=ref，Extra 不再出现 Using filesort EXPLAIN SELECT id, order_no, pay_amount, status FROM order_master WHERE user_id = 10001 AND status = 1 ORDER BY created_at DESC LIMIT 10;

解决：按查询模式建复合索引。用户端建 (user_id, status, created_at)，商家端建 (merchant_id, status, created_at)。顺序不能乱：等值条件字段放最左，排序字段放最后。把 status 放中间，是为了让"用户某状态下订单列表"这个更常见的查询能同时走等值过滤和排序。

5.4 配送状态用 VARCHAR 存中文字符串，统计时口径崩了

现象：delivery 表的 status 字段是 VARCHAR(20)，插入时有的写"已接单"，有的写"接单"，有的写"已接单 "带个空格。运营要统计各环节转化率，SQL 里WHERE status = '已接单'每次查出来的数量都不一样，数据报表成了玄学。

原因：自由字符串对取值没有任何约束，开发、测试、运营都可能用不同写法录入同一个业务状态。VARCHAR 索引对中文字符串的等值匹配也不如整数高效。

解决：状态字段用 TINYINT 加注释定义枚举，比如 0=待接单、1=已接单、2=取件中、3=配送中、4=已送达、5=异常。代码层用常量类统一定义，禁止在 SQL 里写死中文状态。存量数据先跑一条 UPDATE 把字符串映射成数字，再改表结构。如果还没上线，直接在建表阶段就把类型定成 TINYINT，最省事。

5.5 外键约束和导入顺序冲突，删表和灌数据时连环报错

现象：项目里给 order_item 表加了物理外键指向 order_master，给 dish_sku 表加了外键指向 dish。做数据迁移时想清空业务数据重新灌数，先 DELETE order_item 被外键拦住，先 DELETE order_master 又被 order_item 的外键拦住，报一堆 Foreign key constraint fails。

原因：物理外键要求删除父表数据时，子表不能有对应的引用行。批量清理数据时没按依赖顺序操作，就会被约束卡住。

解决：方案有两个。一是清理时先关外键检查：

SET FOREIGN_KEY_CHECKS = 0; DELETE FROM order_master; -- 执行其他清理 SET FOREIGN_KEY_CHECKS = 1;

二是干脆不建物理外键，只在应用层维护逻辑外键关系。我的实际倾向是第二种。外卖系统高并发写入场景下，物理外键带来的额外检查开销和死锁风险不值得买单，应用层代码保证引用完整性即可。建表时去掉 FOREIGN KEY 子句，但保留应有的普通索引，查询效率和开发便利性都保留。

6. 扛住并发：EXPLAIN 验证、读写分离与分表的一线实践

这套表结构设计出来，不是建完就能高枕无忧。我每次交付前都会做两件事：验证索引是否被正确命中，以及压一轮并发下单。EXPLAIN 是最好的验证工具，下单接口和列表查询各抽两条 SQL 出来 EXPLAIN，盯着 type 列看：const、ref、range 都算正常，出现 ALL 就说明索引没建对。

压测层面，用一个并发脚本打 50 个线程，每个线程循环下单，观察有没有超卖和死锁异常。死锁出现先别慌，SHOW ENGINE INNODB STATUS里的 LATEST DETECTED DEADLOCK 会给出冲突的两个事务和锁定行，按第 4 章讲的统一锁顺序去对齐代码通常就能解决。

单量上来后，我会优先做主从读写分离：写库扛订单创建事务，读库扛用户列表和商家后台查询。主从延迟秒级，对"查订单"这种允许秒级滞后的业务完全够用。再往上，订单表可以按 user_id 做水平分表，128 张表，路由规则用 user_id % 128。但分表有代价：一旦分了，跨表查询和全局排序就难做。所以早期设计订单主表时，我刻意把列表查询都设计成"先定位用户再查"的形态，就是为了给分表留后路。

外卖系统的表结构设计没有银弹，但方向是对的：实体边界画清楚、金额用对类型、索引跟着查询走、状态用枚举管理、下单事务统一锁顺序。做到这五点，一个日订单量几千单的系统数据库层面基本不会出大岔子。量级再上一个台阶，再考虑分库分表、引入消息队列做订单和库存解耦。我自己的习惯是每次上线前重新过一遍这几张核心表的 DDL，跟需求文档逐字对照，因为这个阶段改一行字段的代价，远低于上线后加字段的代价。希望这些实战经验对你有帮助，也希望你的外卖系统第一版就能把这些坑全避过去。

本文还有配套的精品资源，点击获取