简介一份面向数据库课程设计的完整报告文档以外卖点餐管理系统为选题从项目背景、用户需求调查、数据流图与数据字典到总体设计、功能模块划分和系统实现均有详细阐述。内容覆盖管理员、店铺、客服、送货员、订单及配送等核心数据对象并给出了MySQL数据库设计思路与Python交互实现方案适合高校计算机相关专业学生撰写数据库课程设计报告时参考借鉴。资源包共含1个docx文件大小2.92MB排版结构清晰包含数据项定义、处理过程说明等完整章节可直接用于理解报告写法与数据库设计流程。目前已有165人学习对于需要快速搭建设计框架、梳理功能模块和数据结构的学生来说具有较高的实用价值。1. 外卖点餐管理系统做数据库课程设计这门课真正考的是把表立住外卖点餐管理系统的数据库课程设计选这个题目的同学很多但从“会建表”做到“能把设计讲清楚”的其实很少。我帮不少人复盘过这类报告最后拉开分数差的不是前端页面多漂亮而是订单明细怎么拆、下单流程里有没有事务保护、库存扣减能不能防超卖这几件事。这篇笔记就按数据库设计的完整路径走一遍从识别实体开始到关系模式、建表 DDL、视图与存储过程最后一章是答辩前值得做的一遍自检。适合正在写这份报告、并且打算照着把系统真正落地的同学。2. 从需求到ER模型先厘清谁在下单、订单长什么样2.1 先定系统边界五个实体够不够谁能合并谁必须拆开外卖点餐的业务主干可以拆成五张表用户、商家、菜品、订单、订单明细。很多同学拿到题目后急着画 ER 图一上来就把购物车、优惠券、配送员、评价、地址全画进去结果实体和联系越画越多报告写到后面自己都解释不清。我一般建议先做一个约束课程设计这个量级把“用户能下单、商家能出餐”讲透就够购物车可以并入“加入订单”这个动作地址可以直接作为用户或订单的冗余字段评价属于可选扩展时间不够就先不建。边界定好后再谈实体识别就简单了。用户和商家是两类不同账号必须分开。菜品归属于商家而且同一个菜品在不同商家可以同名不同价所以菜品不能只存名字必须通过shop_id挂到商家下面。用户在系统里下订单一个订单包含多个菜品同一个菜品可以被多个订单购买这就构成了订单与菜品之间的多对多关系。多对多关系在外卖场景里有个天然的问题一个订单下单时每个菜品买了几份、当时的单价是多少、有没有做特殊备注这些信息没法直接塞进订单主表也没法直接挂在菜品表上。解决办法就是拆出一张订单明细表把订单和菜品之间的多对多转成订单到明细的一对多、菜品到明细的一对多。这一步做对了后面的数据统计才站得住。我见过不少翻车报告订单表里用一个字段存“1号菜3份、2号菜2份”这种自然语言查询时完全没法聚合属于早期设计没拆表导致的债。另一个容易被忽略的点是订单本身的归属。用户下单订单要同时关联用户和商家所以订单表里会同时出现user_id和shop_id两个外键。有人会把订单挂在用户下面而不关联商家结果商家后台接单时找不到自己的待处理订单最后不得不在应用层按shop_id去查结构就很别扭。正确的做法是凡是业务上存在“一方拥有多个子记录”的关系子表就必须带上对方的完整外键链。2.2 ER 图转关系模式一对多、多对多分别怎么落表从 ER 图转关系模式核心规则其实只有两条一对多关系把外键放在“多”的一方多对多关系必须拆中间表。外卖系统的实体关系按这个规则可以直接落成下面这张表。下面这个表格可以直接抄进报告的概念结构设计章节比画一堆连接线更容易被看懂。实体/联系落表方式关键外键说明用户下单用户表与订单表订单表存user_id一对多外键放在订单表商家接单商家表与订单表订单表存shop_id一对多外键放在订单表商家发布菜品商家表与菜品表菜品表存shop_id一对多外键放在菜品表订单包含菜品拆订单明细表明细表存order_id、dish_id多对多拆中间表菜品被明细引用订单明细表明细表存dish_id菜品多次出现在不同订单落表时还有一个很容易犯的错把联系做成属性。比如“用户下订单”有人会在用户表里加一个order_list字段或者把下单时间放在用户表里这都违背了关系模式的基本思想。联系应当体现在外键上而不是体现在“把对方的主键拼成一个字符串”上。判断自己做得对不对就看你能否在纸上写出这样一句话一条订单记录可以通过user_id找到唯一用户通过shop_id找到唯一商家通过订单明细里的order_id找到它包含的所有菜品。写得出表就是对的写不出回去改模型。2.3 范式与快照为什么明细表里要“故意冗余”菜名和单价范式是这门课的理论重点但外卖订单里有一个反范式的地方几乎每个认真做的项目都会遇到订单明细里必须冗余菜品名和下单时的单价。原因很简单菜品价格是变动的。用户下单时一份宫保鸡丁卖 18 元商家第二天改价 22 元如果订单明细不存当时的单价只存dish_id那历史订单的金额、商家月报表、用户订单回看全部会跟着新价格走账就对不上了。这属于典型的时间快照问题。数据库第三范式要求消除冗余但业务层面要求“订单生成那一刻的状态被冻结”所以dish_name和price这两个冗余字段是故意加进去的。我习惯在这个地方向报告里写一句设计说明范式保证的是结构合理性快照保证的是业务正确性两者冲突时业务优先。老师问到“你这里违反了第三范式怎么办”这就是现成的回答。同理订单表里冗余一个shop_name、用户表里冗余address也都能用同样逻辑支撑但冗余要克制别整表都是冗余字段。3. 建库建表手写一份能扛住并发下单的 DDL3.1 字符集、引擎与字段类型这些基础选项别乱选建表之前先把三个基础选项定下来。字符集我固定用utf8mb4不是utf8因为外卖订单的菜品名、备注里经常出现 Emoji 和部分生僻字utf8mb4才能完整存下。排序规则用utf8mb4_0900_ai_ci或utf8mb4_general_ci都行前者是 MySQL 8.0 默认后者兼容性更好课程设计选哪个都不会错。存储引擎必须选InnoDB因为只有它支持事务和行级锁外卖下单是典型的高并发写场景MyISAM没有事务保护并发扣库存很可能超卖。字段类型有几个常见的取舍。主键用INT UNSIGNED就够用如果要演示“海量订单”再往BIGINT靠我在下面的 DDL 里统一用INT UNSIGNED方便新手阅读价格一律DECIMAL(10,2)不要用FLOAT或DOUBLE二进制浮点存金额会出精度问题这是后面避坑章节要展开讲的时间用DATETIME不用TIMESTAMP那东西有 2038 年上限做课程设计没必要留下这种隐患。表名尽量避开保留字比如订单表用orders而不是order看似小事却能少掉一堆反引号的麻烦。3.2 五张核心表的 DDL直接照着改就能用下面这五张表是按外卖业务主干拆出来的字段做了适度冗余索引只保留最常用的查询路径。直接复制到 MySQL 8.0 环境里就能执行注释我写在了关键位置上。-- 用户表支撑登录、个人信息与历史订单关联 CREATE TABLE user ( user_id INT UNSIGNED AUTO_INCREMENT COMMENT 用户ID主键, phone VARCHAR(20) NOT NULL COMMENT 登录手机号唯一, nickname VARCHAR(64) NOT NULL DEFAULT COMMENT 昵称, address VARCHAR(200) NOT NULL DEFAULT COMMENT 默认收货地址, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间, PRIMARY KEY (user_id), UNIQUE KEY uk_phone (phone) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;-- 商家表外卖平台上的店铺主体 CREATE TABLE shop ( shop_id INT UNSIGNED AUTO_INCREMENT COMMENT 商家ID主键, shop_name VARCHAR(100) NOT NULL COMMENT 店铺名称, phone VARCHAR(20) NOT NULL COMMENT 商家联系电话, address VARCHAR(200) NOT NULL DEFAULT COMMENT 门店地址, status TINYINT NOT NULL DEFAULT 1 COMMENT 营业状态1营业 0休息, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 入驻时间, PRIMARY KEY (shop_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商家表;-- 菜品表归属于商家一个商家多个菜品 CREATE TABLE dish ( dish_id INT UNSIGNED AUTO_INCREMENT COMMENT 菜品ID主键, shop_id INT UNSIGNED NOT NULL COMMENT 所属商家ID, dish_name VARCHAR(100) NOT NULL COMMENT 菜品名称, category VARCHAR(50) NOT NULL DEFAULT COMMENT 分类如热菜/凉菜/饮品, price DECIMAL(10,2) NOT NULL COMMENT 现售单价, stock INT UNSIGNED NOT NULL DEFAULT 0 COMMENT 当日库存, status TINYINT NOT NULL DEFAULT 1 COMMENT 上架状态1上架 0下架, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (dish_id), KEY idx_shop_category (shop_id, category), CONSTRAINT fk_dish_shop FOREIGN KEY (shop_id) REFERENCES shop (shop_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT菜品表;-- 订单表一次下单生成一条主记录 CREATE TABLE orders ( order_id INT UNSIGNED AUTO_INCREMENT COMMENT 订单ID主键, user_id INT UNSIGNED NOT NULL COMMENT 下单用户ID, shop_id INT UNSIGNED NOT NULL COMMENT 接单商家ID, total_amount DECIMAL(10,2) NOT NULL COMMENT 订单总金额, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0待支付 1已支付 2制作中 3配送中 4已完成 5已取消, address VARCHAR(200) NOT NULL DEFAULT COMMENT 配送地址下单时快照, remark VARCHAR(200) NOT NULL DEFAULT COMMENT 用户备注, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 下单时间, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 状态更新时间, PRIMARY KEY (order_id), KEY idx_user_create (user_id, create_time), KEY idx_shop_status (shop_id, status), KEY idx_create_time (create_time), CONSTRAINT fk_orders_user FOREIGN KEY (user_id) REFERENCES user (user_id), CONSTRAINT fk_orders_shop FOREIGN KEY (shop_id) REFERENCES shop (shop_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;-- 订单明细表订单与菜品的多对多拆解 CREATE TABLE order_item ( item_id INT UNSIGNED AUTO_INCREMENT COMMENT 明细ID主键, order_id INT UNSIGNED NOT NULL COMMENT 所属订单ID, dish_id INT UNSIGNED NOT NULL COMMENT 菜品ID, dish_name VARCHAR(100) NOT NULL COMMENT 菜品名称快照, price DECIMAL(10,2) NOT NULL COMMENT 下单时单价快照, quantity INT UNSIGNED NOT NULL DEFAULT 1 COMMENT 购买数量, subtotal DECIMAL(10,2) NOT NULL COMMENT 小计金额 price * quantity, PRIMARY KEY (item_id), KEY idx_order (order_id), KEY idx_dish (dish_id), CONSTRAINT fk_item_order FOREIGN KEY (order_id) REFERENCES orders (order_id), CONSTRAINT fk_item_dish FOREIGN KEY (dish_id) REFERENCES dish (dish_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单明细表;这套 DDL 里值得注意的地方有三个。第一订单表上面建了三个索引分别对应“用户查历史订单”“商家查待处理订单”“按时间做统计”三类高频查询但不要继续乱加索引是读优化的代价写一次要维护一次。第二明细表里dish_name和price就是刻意冗余的快照字段和菜品表里的当前数据解耦。第三外键约束我建议保留课程设计阶段数据库是单一系统外键能保证主数据不被随意破坏如果是生产环境的高并发分库分表外键常常被去掉这个在第 5 章会专门讲。3.3 索引不是越多越好每个索引都要能说出一个查询来见过不少同学建表时把每个字段都建索引理由是“这样查询快”。真实的场景是索引越多插入和更新越慢因为每次写都要同步维护所有索引。我给自己定过一条原则建索引前先问自己“为哪个查询建的”说不上来就删掉。订单表里的idx_user_create是典型的复合索引设计依据是用户端高频操作“查看我的历史订单”查询条件是WHERE user_id ? ORDER BY create_time DESC让user_id走等值、create_time走排序一次索引就能命中。idx_shop_status服务于商家端后台的“待接单列表”条件一般是WHERE shop_id ? AND status 1。idx_create_time单独建是因为平台方要按天统计订单量如果不建WHERE create_time BETWEEN ... AND ...会全表扫描。每个索引背后站着一个查询这样的设计才禁得起老师在答辩时追问。4. 让数据库自己干活视图、存储过程与触发器4.1 视图写热销榜把聚合逻辑收进数据库里视图的价值是把复杂的统计 SQL 封装起来让上层应用像查表一样查结果。外卖系统里最常用的视图是“菜品销售统计”它来自订单明细表通过GROUP BY聚合销量。CREATE VIEW v_dish_sales AS SELECT d.dish_id, d.dish_name, d.shop_id, IFNULL(SUM(oi.quantity), 0) AS sale_quantity, IFNULL(SUM(oi.subtotal), 0) AS sale_amount FROM dish d LEFT JOIN order_item oi ON d.dish_id oi.dish_id GROUP BY d.dish_id, d.dish_name, d.shop_id;视图里只做聚合不做最终的排序和分页。很多同学在视图里写ORDER BY sale_quantity DESC LIMIT 10这个写法在 MySQL 里会留下隐患视图本身是个虚拟表外层查询加上别的条件时内层排序可能失效。正确用法是外面再套一层SELECT * FROM v_dish_sales ORDER BY sale_quantity DESC LIMIT 10。另外注意我用了LEFT JOIN因为没有卖过的菜品也要留在榜单里销量为 0 而不是消失这样商家端能看出哪些菜滞销。4.2 存储过程一次下单的“事务剧本”下单是外卖系统里事务性最强的操作写入订单主表、写入多条明细、扣减菜品库存、计算总金额这些步骤要么全部成功要么全部回滚。我习惯把整个流程封装成一个存储过程应用层只调一个入口数据库自己保证一致性。下面是 MySQL 8.0 的实现用 JSON 参数接收购物车内的菜品数组然后借助JSON_TABLE展开成明细。DELIMITER $$ CREATE PROCEDURE sp_create_order( IN p_user_id INT UNSIGNED, IN p_shop_id INT UNSIGNED, IN p_address VARCHAR(200), IN p_remark VARCHAR(200), IN p_items JSON COMMENT 菜品数组如[{dish_id:1,quantity:2}] ) BEGIN DECLARE v_order_id INT UNSIGNED; DECLARE v_total DECIMAL(10,2) DEFAULT 0; DECLARE v_done INT DEFAULT 0; DECLARE v_dish_id INT UNSIGNED; DECLARE v_qty INT UNSIGNED; -- 1. 用临时表承载展开后的菜品列表方便逐行核查 CREATE TEMPORARY TABLE tmp_items ( dish_id INT UNSIGNED NOT NULL, quantity INT UNSIGNED NOT NULL ) ENGINEInnoDB; INSERT INTO tmp_items (dish_id, quantity) SELECT jt.dish_id, jt.quantity FROM JSON_TABLE( p_items, $[*] COLUMNS ( dish_id INT UNSIGNED PATH $.dish_id, quantity INT UNSIGNED PATH $.quantity ) ) AS jt; START TRANSACTION; -- 2. 校验每个菜品是否属于当前商家且处于上架状态 -- 这里存在细粒度行锁写代码时要当心死锁第5章会展开 SELECT COUNT(*) INTO v_done FROM tmp_items t JOIN dish d ON d.dish_id t.dish_id WHERE d.shop_id p_shop_id AND d.status 1; IF v_done (SELECT COUNT(*) FROM tmp_items) THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 存在无效菜品或非本店菜品; END IF; -- 3. 逐行扣减库存先锁行再检查库存够不够 DECLARE cur CURSOR FOR SELECT dish_id, quantity FROM tmp_items; DECLARE CONTINUE HANDLER FOR NOT FOUND SET v_done 1; OPEN cur; read_loop: LOOP FETCH cur INTO v_dish_id, v_qty; IF v_done 1 THEN LEAVE read_loop; END IF; UPDATE dish SET stock stock - v_qty WHERE dish_id v_dish_id AND stock v_qty; IF ROW_COUNT() 0 THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 库存不足; END IF; END LOOP; CLOSE cur; -- 4. 统计总金额并生成订单主记录 SELECT IFNULL(SUM(d.price * t.quantity), 0) INTO v_total FROM tmp_items t JOIN dish d ON d.dish_id t.dish_id; INSERT INTO orders (user_id, shop_id, total_amount, status, address, remark) VALUES (p_user_id, p_shop_id, v_total, 0, p_address, p_remark); SET v_order_id LAST_INSERT_ID(); -- 5. 批量写入订单明细注意这里的 price 来自菜品当前价属于下单时快照 INSERT INTO order_item (order_id, dish_id, dish_name, price, quantity, subtotal) SELECT v_order_id, d.dish_id, d.dish_name, d.price, t.quantity, d.price * t.quantity FROM tmp_items t JOIN dish d ON d.dish_id t.dish_id; -- 6. 清理临时表并提交事务 DROP TEMPORARY TABLE IF EXISTS tmp_items; COMMIT; END$$ DELIMITER ;调用存储过程的语句长这样CALL sp_create_order(1, 2, 某小区3号楼, 少辣, JSON_ARRAY(JSON_OBJECT(dish_id, 1, quantity, 2)));这里面的关键点我得说明白。临时表tmp_items只服务当前会话不会被其他事务看到用完立刻删除。游标逐行扣库存是为了处理“多种菜品各扣各的”场景每次UPDATE都带stock qty条件相当于在一条语句里完成检查和扣减不需要先SELECT再UPDATE这样能避免并发下读到旧库存。总金额不用前端传由数据库重新计算一次这是防止篡改金额的基本手段。值得注意的是DECLARE在存储过程里的位置有讲究游标声明必须放在变量声明之后、其他语句之前位置放错会直接报语法错误这是一处很容易让新手卡半小时的地方。4.3 触发器的取舍状态日志够用别把核心逻辑都塞进去触发器在外卖系统里最适合做的是“审计日志”比如订单状态一变自动往日志表里写一条记录。下面这个触发器在orders表任何一行status被更新时触发把老状态和新状态都留下来。CREATE TABLE order_status_log ( log_id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_id INT UNSIGNED NOT NULL, old_status TINYINT NOT NULL, new_status TINYINT NOT NULL, change_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; DELIMITER $$ CREATE TRIGGER trg_order_status_log AFTER UPDATE ON orders FOR EACH ROW BEGIN IF OLD.status NEW.status THEN INSERT INTO order_status_log (order_id, old_status, new_status) VALUES (NEW.order_id, OLD.status, NEW.status); END IF; END$$ DELIMITER ;这个触发器看着漂亮但我要提醒一句触发器能不用就不用。它是隐式逻辑业务代码里看不到它出问题时很难排查而且它和事务绑在一起主表更新失败日志也不会写。课程设计里放一到两个触发器展示能力即可不要把库存扣减、金额计算这类核心逻辑塞进触发器。不然老师换个场景问“这个触发器性能开销你怎么算”你会被自己挖的坑绊倒。5. 订单库表设计的高频翻车点常见问题排查与避坑实录5.1 金额字段用 FLOAT订单总额差了一分钱现象订单明细单价没问题但统计某天营收时总和与每单total_amount对不上少则一分多则几毛。有位同学排查了一下午最后发现是price字段建表时用了FLOAT。原因FLOAT和DOUBLE是二进制浮点无法精确表示所有十进制小数。0.1 在二进制里是无限循环小数累加多笔后误差自然显现而DECIMAL是定点数按十进制整数存储精算金额只能用它。解决所有金额字段统一DECIMAL(10,2)包括单价、小计、总额。如果以后要做更大规模系统整数分存储是另一个方案但课程设计用DECIMAL最直接别再给自己找麻烦。5.2 外键被随意删数据成了孤儿现象有人嫌外键影响插入速度建表时把CONSTRAINT全砍了。结果删菜品时没人检查引用订单明细里留下大量指向不存在菜品的记录统计报表JOIN之后数据神秘变少。原因外键本质是数据库层面的引用完整性约束。课程设计阶段没有分库分表也没有微服务拆库外键带来的性能损耗可以忽略反而是“手下留情”的数据完整性漏洞更致命。解决主表关联字段要么建外键要么在建表后写一个应用层的级联删除逻辑。最省事的做法是我在 DDL 里展示的保留外键如果演示时需要删商家先把关联订单处理完再删主表。答辩时如果被问“生产环境为什么不用外键”可以说分库后外键无法跨库约束但前提是先把完整性问题讲清楚。5.3 订单数据膨胀后查询越来越慢现象前期几千条订单时秒开演示前用脚本灌了十万条数据商家端“本月订单”页面直接卡到超时EXPLAIN一看typeALL全表扫描。原因订单表只建了主键索引没建shop_id status复合索引按商家和状态过滤时只能逐行扫全表。这个坑的可怕之处在于数据量少的时候根本暴露不出来等到上线或答辩前灌数据才爆发。解决按第 3 章的 DDL 补上idx_shop_status和idx_user_create然后跑一遍EXPLAIN SELECT * FROM orders WHERE shop_id2 AND status0确认key指向了这个索引。更进一步的方案是分区表或归档历史订单但对课程设计来说正确建立复合索引已经足够不要为了炫技去做无谓的水平扩展。5.4 并发下单时死锁库存没扣成现象用压测工具同时发 20 个下单请求日志里间歇性报死锁错误Deadlock found when trying to get lock一部分订单回滚重试后成功一部分直接失败。原因多个事务按不同顺序更新同一批菜品行。事务 A 先扣菜品 1 再扣菜品 2事务 B 先扣菜品 2 再扣菜品 1各占一行等对方释放形成环路等待。这正是 InnoDB 行级锁的经典死锁场景。解决两个办法同步用。第一所有事务内按固定顺序更新菜品比如按dish_id升序让所有并发请求都按同一路径拿锁。第二在存储过程中对死锁重试捕获到ER_LOCK_DEADLOCK就回滚后重新执行。课程设计能过前一半就已经很稳重试逻辑可以作为加分项写进报告的“异常处理”部分老师非常吃这一套。5.5 没有备份习惯答辩前误删了订单表现象演示前想清掉测试数据一个DROP TABLE下去删错了表当时脑子里只有一个念头这课设完了。查半天找不到快速恢复的办法白白重做了一遍。原因本地开发太顺手没人建库前先备份。课程设计虽然数据量小但 MySQL 的误删恢复流程和生产是一模一样的没有备份就只能靠binlog碰运气。解决开工第一天就把备份养成习惯。全量备份用一条mysqldump就行完整命令是mysqldump -u root -p 外卖库名 backup_$(date %Y%m%d).sql恢复时执行mysql -u root -p 外卖库名 backup_xxx.sql。每天更新一次改表结构前先备一份答辩当天早上再备一份。这是你给自己留的后悔药成本极低收益极高。6. 把“能跑”做成“能答辩”EXPLAIN 和压测来自证设计课程设计的验收标准和代码上线不一样光功能能跑只算及格能把“为什么这么设计”讲清楚才算优秀。我给自己养成过的习惯是答辩前用一小时做三件小事第一件是生成几万条模拟数据第二件是给报告里每条核心查询跑一遍EXPLAIN第三件是准备一个设计亮点。模拟数据生成不需要写复杂脚本写一段存储过程循环插入下单记录就行订单表数据量上到五万条以上查询性能问题才会露头。EXPLAIN是最直接的自证手段。挑报告里三个高频查询分别执行EXPLAIN SELECT 字段 FROM orders WHERE user_id某值 ORDER BY create_time DESC和EXPLAIN SELECT * FROM orders WHERE shop_id某值 AND status0把输出结果里type和key两列截个图放进报告的优化章节。type是ref或range、key不是NULL就说明索引设计站得住脚如果显示ALL答辩前赶紧补索引这一眼就能看出你到底有没有真跑过数据。设计亮点方面我推荐在报告里加一个“限时秒杀场景的库存控制”小节直接引用第 4 章的存储过程说明UPDATE dish SET stock stock - 1 WHERE dish_id ? AND stock 0这一条语句如何利用行锁原子地完成“检查与扣减”避免先查后改的竞态条件。再配合上死锁重试的伪代码这个方案在课程设计里已经算深度较厚的设计了。我早期做类似系统时只顾着把页面做漂亮完全没跑过EXPLAIN答辩现场被问“你这几条 SQL 走索引了吗”我愣了半天说不出话那个尴尬直到现在都记得。希望你不用重走这一趟把设计做扎实再站上台希望帮到你。本文还有配套的精品资源点击获取
