简介MyShop 商城系统数据库设计资源包面向需完成 MySQL 课程设计、毕业设计或希望掌握电商数据库设计方法的初学者与开发者。资源围绕用户、地址、商品、购物车、订单与订单项六大核心数据模块展开并从用户管理、商品管理、购物车管理、订单管理、地址管理等处理需求入手给出商城后台典型业务场景下的完整设计思路可帮助读者理解实体关系、业务边界、权限控制与订单流转等关键环节。压缩包整体大小约 196.67MB资源粒度适中既适合在课程设计时参照搭建数据库原型也适合电商项目前期的数据建模与表结构规划。内容兼顾数据需求分析与处理需求分析两条主线便于对照业务功能逐层展开设计。已有 393 人学习/下载适合需要从零梳理商城数据库全流程的初学者以及希望借助完整案例巩固 MySQL 设计能力的开发者。1. 购物网站数据库设计一次库存超卖演示翻车后的完整建模方案A同学拿着自己做的购物网站课设去演示导师让他现场模拟两个账号同时抢一件只剩 1 件库存的商品结果操作完一看库存变成了 -2订单却生成了 3 条。问题不出在他写的业务代码上而是整个 MySQL 数据库只有一张商品表加一张订单表没有事务、没有锁、没有库存校验。购物网站的数据库设计不是简单地建几张表存数据而是要从业务流程反推实体关系再落到索引、事务、并发控制的完整方案。这篇文章就以「MySQL 数据库应用」最常见的选题——购物网站系统为例从需求分析、E-R 设计、建表 DDL、下单事务到验收测试给出一套可以直接参考甚至照搬的数据库设计方案。2. 需求分析与概念设计从购物流程拆出六个核心实体2.1 业务流程梳理先弄清楚数据从哪来、往哪去购物网站的数据库设计第一步不是打开 MySQL 建表而是先把业务流程画出来。这个步骤看着浪费时间实际上决定了后面表之间的关系对不对。一个标准的购物流程是这样用户注册并登录维护个人资料和收货地址浏览商品分类和商品列表查看商品详情将商品加入购物车修改数量勾选商品后提交订单支付订单、商家发货、用户确认收货后台管理商品分类、上下架商品、处理订单状态。从这条链路能看出数据不是零散堆在一起的它有明确的流向。用户在商品详情页看到的价格要跟订单里记录的价格保持一致购物车里的商品在生成订单后要被清空订单状态从待支付到已完成要由多个字段承载。通常的做法是先把业务流程中每个环节涉及的数据名称列出来再归并成实体和属性。这一步能避免后面反复改表结构也能让答辩时的 E-R 图有据可依。我在设计这一步时习惯用一个表整理各环节的数据需求用户登录环节需要用户名和密码商品浏览环节需要分类和价格下单环节需要商品ID、数量、单价、收货人信息支付环节需要订单号、支付时间、支付金额。把这些梳理清楚后再进入实体设计就不会乱。2.2 实体与关系六个核心实体之间的三种联系类型购物网站最典型的实体有六个用户、商品分类、商品、库存、购物车、订单。其中订单还要拆出一个明细实体来记录订单包含哪些商品所以最终的物理表通常是七到八张。它们之间的关系可以归纳为三种用户与订单一对多一个用户可以下多个订单商品与订单明细一对多一个商品可以出现在多个订单明细中用户与购物车一对多购物车中的每条记录是某个用户对某件商品的一次加购。这里特别要提的是订单与订单明细的关系。订单主表存的是订单的整体信息比如总金额、支付状态、收货地址订单明细表存的才是这个订单买了哪些商品、每件商品当时的单价和数量。为什么要把价格冗余一份到明细表因为商品价格会变动下单之后如果商品改价订单里的成交价不能跟着变。这个冗余在数据库设计里看起来违反第三范式但在电商业务里是必要的属于为业务正确性买单的合理冗余。商品与库存的关系也值得注意。很多课设会把库存字段直接放在商品表里这种做法在商品数量少、并发低的时候没问题但如果要演示限时抢购场景独立的库存表更容易配合锁机制做扣减。我一般会把库存拆成单独一张表字段包括可用库存、锁定库存和版本号后面讲并发控制时会用到。2.3 逻辑设计主键、外键与范式取舍逻辑设计阶段要确定每张表的主键和约束策略。主键统一使用自增整数类型 BIGINT UNSIGNED AUTO_INCREMENT理由是写入性能好、索引占用小、唯一性稳定。用户名要加唯一索引订单号必须加唯一索引购物车表用用户ID加商品ID的组合唯一索引这几个唯一约束直接决定了并发下不会出现重复数据。外键这里有个常见的分叉。课设里为了方便画 E-R 关系图很多人会建立物理外键让数据库自己保证引用完整性。但实际开发中物理外键在删除和更新时会引入额外的锁和校验开销高并发下容易成为瓶颈所以生产环境普遍的做法是逻辑外键——表结构里保留关联字段但不创建 FOREIGN KEY 约束由应用层保证数据一致性。如果你的课程设计要求必须体现外键可以在设计文档里说明逻辑外键的理由反倒能成为答辩的加分项。范式方面我不建议把三范式当作教条。用户表和订单表之间隔了收货地址表设计上可以用外键关联但订单表直接冗余收货人姓名、电话、地址字段会更稳妥——因为订单是历史记录地址变更不能影响历史订单的展示。类似这种「以空间换正确性」的取舍在电商数据库里比比皆是理解它比背范式定义重要得多。3. 表结构设计与建表实现MySQL 核心 DDL 逐表拆解3.1 用户与商品模块user、category、product、inventory 四张表用户表是整套设计的起点。密码字段用 CHAR(64) 存哈希值而不是明文status 字段做逻辑删除避免物理删除导致关联数据丢失。建表语句如下CREATE TABLE user ( user_id BIGINT UNSIGNED AUTO_INCREMENT COMMENT 用户ID, username VARCHAR(50) NOT NULL COMMENT 登录名, password CHAR(64) NOT NULL COMMENT 密码SHA-256哈希值, nickname VARCHAR(50) DEFAULT COMMENT 昵称, phone VARCHAR(20) DEFAULT COMMENT 手机号, email VARCHAR(100) DEFAULT COMMENT 邮箱, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 0禁用, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (user_id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;username 上的唯一索引 uk_username 是并发注册场景下的最后一道防线代码里先查重再插入并不能百分百防重只有数据库唯一约束才能兜底。update_time 用 ON UPDATE CURRENT_TIMESTAMP 可以在每次修改时自动刷新省去应用层手动维护的时间字段。商品分类表支持二级分类parent_id 为 0 表示一级分类。商品表单独存价格和上架状态不直接放库存为的是让库存变化不影响商品基础信息的读写CREATE TABLE category ( category_id SMALLINT UNSIGNED AUTO_INCREMENT COMMENT 分类ID, parent_id SMALLINT UNSIGNED NOT NULL DEFAULT 0 COMMENT 父分类ID0为一级分类, category_name VARCHAR(50) NOT NULL COMMENT 分类名称, sort_order TINYINT NOT NULL DEFAULT 0 COMMENT 排序值越小越靠前, PRIMARY KEY (category_id), KEY idx_parent_id (parent_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品分类表; CREATE TABLE product ( product_id BIGINT UNSIGNED AUTO_INCREMENT COMMENT 商品ID, category_id SMALLINT UNSIGNED NOT NULL COMMENT 所属分类ID, product_name VARCHAR(200) NOT NULL COMMENT 商品名称, subtitle VARCHAR(500) DEFAULT COMMENT 副标题, main_image VARCHAR(255) DEFAULT COMMENT 主图URL, detail TEXT COMMENT 商品详情HTML, price DECIMAL(10,2) NOT NULL COMMENT 当前售价, status TINYINT NOT NULL DEFAULT 1 COMMENT 1上架 0下架, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (product_id), KEY idx_category_id (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;这里的索引策略是商品表只对 category_id 建普通索引因为商品名很少用等值查询更多是模糊搜索模糊搜索走索引性价比不高。如果课程设计里要求支持商品名搜索可以在设计文档里补一句「实际项目中会用全文索引或搜索引擎本方案聚焦核心交易链路」。库存表单独拆出来用 product_id 做主键这是典型的一对一关系。version 字段留给乐观锁使用CREATE TABLE inventory ( product_id BIGINT UNSIGNED NOT NULL COMMENT 商品ID与商品表一一对应, stock INT NOT NULL DEFAULT 0 COMMENT 可售库存, locked_stock INT NOT NULL DEFAULT 0 COMMENT 锁定库存支付中冻结, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本号每次更新加1, PRIMARY KEY (product_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT库存表;3.2 购物车与订单模块cart、orders、order_item 三张表购物车表用 user_id 和 product_id 做联合唯一索引实现同一个用户对同一件商品只有一条购物车记录。这样加购时可以直接执行 INSERT ... ON DUPLICATE KEY UPDATE 来累加数量省去先查再改的步骤CREATE TABLE cart ( cart_id BIGINT UNSIGNED AUTO_INCREMENT COMMENT 购物车条目ID, user_id BIGINT UNSIGNED NOT NULL COMMENT 用户ID, product_id BIGINT UNSIGNED NOT NULL COMMENT 商品ID, quantity INT NOT NULL DEFAULT 1 COMMENT 数量, checked TINYINT NOT NULL DEFAULT 1 COMMENT 是否勾选 1是 0否, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 加入时间, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (cart_id), UNIQUE KEY uk_user_product (user_id, product_id), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT购物车表;orders 表是整张设计的核心字段设计上有两个关键点。第一order_no 业务订单号加唯一索引它对外展示给用户对内关联支付流水自增主键 order_id 不暴露给前端。第二收货人信息直接冗余三个字段不关联地址表这样即使地址被修改或删除订单里的收货信息依然是下单那一刻的快照CREATE TABLE orders ( order_id BIGINT UNSIGNED AUTO_INCREMENT COMMENT 订单ID, order_no VARCHAR(32) NOT NULL COMMENT 业务订单号, user_id BIGINT UNSIGNED NOT NULL COMMENT 下单用户ID, total_amount DECIMAL(10,2) NOT NULL COMMENT 订单总金额, pay_status TINYINT NOT NULL DEFAULT 0 COMMENT 0未支付 1已支付 2已退款, ship_status TINYINT NOT NULL DEFAULT 0 COMMENT 0未发货 1已发货 2已收货 3已取消, receiver_name VARCHAR(50) NOT NULL COMMENT 收货人姓名, receiver_phone VARCHAR(20) NOT NULL COMMENT 收货人电话, receiver_address VARCHAR(200) NOT NULL COMMENT 收货地址, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 下单时间, pay_time DATETIME DEFAULT NULL COMMENT 支付时间, PRIMARY KEY (order_id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表;订单明细表保存商品快照。product_name、product_image、price 都从商品表冗余过来这样就算商品之后被删掉或改价用户的订单详情依然能正常展示。明细表只对 order_id 建索引不需要独立的商品索引——查询总是从订单出发CREATE TABLE order_item ( item_id BIGINT UNSIGNED AUTO_INCREMENT COMMENT 明细ID, order_id BIGINT UNSIGNED NOT NULL COMMENT 订单ID, product_id BIGINT UNSIGNED NOT NULL COMMENT 商品ID, product_name VARCHAR(200) NOT NULL COMMENT 商品名称快照, product_image VARCHAR(255) DEFAULT COMMENT 商品主图快照, price DECIMAL(10,2) NOT NULL COMMENT 下单时成交单价, quantity INT NOT NULL COMMENT 购买数量, subtotal DECIMAL(10,2) NOT NULL COMMENT 小计金额, PRIMARY KEY (item_id), KEY idx_order_id (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单明细表;3.3 字段类型与存储引擎为什么金额用 DECIMAL、引擎选 InnoDB字段类型的选择直接决定数据会不会失真。金额字段一律用 DECIMAL(10,2)禁止 FLOAT 和 DOUBLE原因很简单浮点数用二进制表示十进制小数有精度误差0.1 加 0.2 在 FLOAT 里可能算出 0.30000000000000004账目对账的时候会出现莫名其妙的几分钱差异。DECIMAL 是定点数按十进制存储金额计算不会丢精度。字符编码统一用 utf8mb4而不是 utf8mb3 或 latin1。utf8mb4 是完整的 Unicode 编码能存下表情符号和生僻字商品详情、收货地址里出现特殊字符不会报错。排序规则默认用 utf8mb4_unicode_ci 就够了。存储引擎固定 InnoDB。MyISAM 的查询速度在老场景下有一定优势但它不支持事务、不支持行级锁崩溃恢复能力也差。购物网站的核心链路是下单扣库存必须保证事务的原子性和隔离性这个需求直接把 MyISAM 排除掉了。InnoDB 的行级锁也让并发更新同一件商品的库存时不至于把整张表锁死。时间字段统一用 DATETIME带默认值 CURRENT_TIMESTAMP。TIMESTAMP 类型有 2038 年问题而且受时区影响DATETIME 的范围和稳定性更适合业务系统。每个数据表都保留 create_time 和 update_time 两个时间戳字段排查数据问题时能省很多力气。4. 核心业务实现下单事务、库存锁与状态流转4.1 下单流程的事务边界设计下单是购物网站里最典型的事务场景扣库存、写订单、写明细必须同时成功或同时失败。如果先扣了库存再去写订单写订单报错又没有回滚就会出现「库存已扣但订单不存在」的黑匣子问题。一个标准的下单事务 SQL 序列如下START TRANSACTION; -- 1. 锁定库存行防止其他事务同时扣减 SELECT stock FROM inventory WHERE product_id 1001 FOR UPDATE; -- 2. 条件扣减库存stock 1 防止超卖 UPDATE inventory SET stock stock - 1 WHERE product_id 1001 AND stock 1; -- 3. 检查上一步影响行数若为 0 说明库存不足回滚并提示用户 -- 实际由应用层判断 ROW_COUNT() 或 JDBC 返回的更新行数 -- 4. 写入订单主表 INSERT INTO orders (order_no, user_id, total_amount, receiver_name, receiver_phone, receiver_address) VALUES (202406010001, 1, 299.00, 张三, 13800138000, 某市某区某路1号); -- 5. 写入订单明细表 INSERT INTO order_item (order_id, product_id, product_name, price, quantity, subtotal) VALUES (LAST_INSERT_ID(), 1001, 无线鼠标, 299.00, 1, 299.00); COMMIT;这里有两道保险SELECT ... FOR UPDATE 先把库存行锁住防止两个事务同时读到同一个库存值UPDATE 语句里的 stock 1 条件是第二道保险就算之前读到的库存已经过期条件更新也能挡住负数。应用层拿到 UPDATE 的影响行数后如果返回 0 就直接回滚整个事务。事务边界要尽量短不能在事务里做网络请求、发短信、调第三方支付接口这些耗时操作。一个常见的反面写法是事务里先调支付接口等用户扫码支付完成再提交事务结果连接被长时间占用数据库连接池很快被打满。正确的做法是先扣库存生成订单事务提交后再异步去调支付支付结果通过回调更新订单状态。4.2 库存防超卖悲观锁与乐观锁两种方案对比库存扣减是购物网站并发问题的重灾区。悲观锁的做法是在事务内锁定库存行适合并发冲突较多的场景乐观锁则是更新时校验版本号适合读多写少的场景。两种方案的实现我都列出来你可以根据课设的演示需求选一种。悲观锁使用 SELECT ... FOR UPDATE事务提交或回滚时自动释放锁START TRANSACTION; SELECT stock FROM inventory WHERE product_id 1001 FOR UPDATE; -- 业务代码里判断 stock 所需数量不足则回滚 UPDATE inventory SET stock stock - 1 WHERE product_id 1001; INSERT INTO orders (order_no, user_id, total_amount) VALUES (202406010002, 1, 299.00); COMMIT;乐观锁使用版本号字段更新时校验读取到的版本号是否仍然有效-- 第一次读取库存和版本号 SELECT stock, version FROM inventory WHERE product_id 1001; -- 应用层计算新库存然后执行条件更新 UPDATE inventory SET stock stock - 1, version version 1 WHERE product_id 1001 AND version 1; -- 影响行数为 1 说明成功为 0 说明有并发修改需要重试悲观锁的代价是锁等待。两个事务同时锁同一件商品时后到的事务要等前一个事务提交或回滚如果前一个事务执行时间过长后一个会超时。乐观锁没有锁等待但更新失败后需要应用层重试重试次数多了用户体验会下降。课程设计演示通常并发量不大两种都能满足要求如果要讲得更深一层可以在答辩时说秒杀场景用悲观锁保证强一致普通加购场景用乐观锁提升吞吐。4.3 订单号生成与支付状态流转订单号不直接用自增主键原因是主键自增值会被别人猜到而且多表合并时容易冲突。常用的生成方式是时间戳加随机数格式为 yyyyMMddHHmmss 6 位随机数 用户ID后四位长度控制在 32 个字符以内配合订单表的唯一索引 uk_order_no 兜底。即使同一秒内两个用户同时下单随机数加用户ID的尾部组合也几乎不会重复。支付状态和物流状态分开用两个 TINYINT 字段表示不要合成一个状态字段。订单的完整状态流转如下表pay_status含义可流转方向0未支付1 已支付、3 已取消1已支付2 已退款2已退款终态3已关闭终态ship_status 独立管理发货链路0 未发货1 已发货2 已收货。两个字段组合起来可以表达「已支付未发货」「已发货未收货」等中间状态。字段拆开的好处是后台查询可以分别按支付状态和发货状态筛选不需要做复杂的字符串解析。状态更新用带条件的 UPDATE防止状态乱跳例如支付回调里执行UPDATE orders SET pay_status 1, pay_time NOW() WHERE order_id 1001 AND pay_status 0;影响行数为 0 就说明订单已经不是未支付状态直接返回避免重复回调把已支付的订单覆盖成未支付。5. 避坑指南购物网站数据库最容易翻车的五个问题5.1 并发下单导致库存变成负数现象两个账号同时购买同一件只剩 1 件库存的商品系统最终显示库存为 -1而且生成了两条订单。原因应用层先 SELECT 查库存判断大于 0 后再 UPDATE这中间存在时间差。两个请求同时读到 stock1都通过了判断于是各自执行扣减库存就变成了 -1。这类问题用单表、无锁设计时几乎必然出现属于典型的并发读写竞态。解决把扣减和判断合并到一条 UPDATE 语句里用 stock 数量 作为条件。UPDATE inventory SET stock stock - 1 WHERE product_id ? AND stock 1; 再根据影响行数决定是否继续生成订单。同时推荐在库存表增加 version 字段做乐观锁兜底两条防线配合超卖在逻辑上就不可能发生。5.2 订单表数据量增长后查询缓慢现象上线初期订单查询很快数据到几万条后按用户查历史订单越来越慢后台翻页到第 100 页基本要等好几秒。原因最常见的是没在 user_id 上建索引导致每次查询都是全表扫描。另一个原因是深分页LIMIT 10000, 20 需要先扫描前 10000 条再丢弃数据量越大开销越高。解决orders 表的 idx_user_id 索引必须有。分页查询用「上次最大 ID」代替页码或者限制用户只能查看最近三个月的订单从业务层面控制扫描范围。课程设计里能体现这一点会很加分说明你考虑过数据量增长的问题。5.3 物理删除用户导致历史订单查不到现象后台删掉一个测试用户后这个用户的历史订单在管理端也消失了订单汇总数据对不上。原因订单表通过 user_id 以物理外键关联用户表删除用户时 CASCADE 把订单连带删掉了。或者是应用层先删用户再删订单但没有意识到订单是核心交易数据不应该随用户销毁。解决购物网站里用户和订单都只能做逻辑删除。用户表用 status 字段标记禁用订单表不做删除操作只做状态流转。物理外键改为逻辑外键由应用层保证关联字段的有效性。这样保留完整交易链路也符合电商系统的审计要求。5.4 金额字段用了 FLOAT对账时出现几分钱差异现象订单总金额 299.90 元明细加总却显示 299.8999999数据库和前端展示不一致财务对账不平。原因FLOAT 和 DOUBLE 是浮点数用二进制近似表示十进制小数累加时误差会累积。5 分钱的误差在单笔订单上不明显汇总到月度报表就成了大问题。解决所有金额字段统一使用 DECIMAL(10,2)包括订单总额、单价、小计。Decimal 以字符串形式存储十进制数加减乘除不会出现二进制浮点误差。这一点在数据库设计文档的字段类型说明里一定要写清楚。5.5 事务未提交就抛异常连接资源泄漏现象压测时数据库连接数持续增长最终报 Too many connections应用假死。原因下单逻辑里开启了事务中间某一步抛出异常却没有触发回滚事务一直持有连接不释放。或者事务里调用了外部接口外部接口超时事务长时间挂着。连接池耗尽后其他正常请求也拿不到连接。解决代码里用 try-catch 包裹事务边界catch 里显式执行 ROLLBACKfinally 里归还连接。事务内只做数据库操作外部调用一律放到事务提交之后。同时给连接池配置合理的最大连接数和等待超时时间比如最大 50、超时 3 秒这样单个事务异常不会拖垮整个应用。6. 验收与答辩功能测试、并发压测与讲解技巧6.1 功能验收清单一张表跑完所有业务路径验收阶段不要上来就压测先把功能路径走通。准备好测试数据5 个商品分类、每个分类 3 件商品、库存各 10 件、两个测试用户。按下面的清单逐项验证验收项操作方式预期结果用户注册新建账号插入成功用户名重复时被唯一索引拦截商品浏览按分类查询商品只返回 status1 的上架商品加入购物车同一商品反复加购购物车记录不重复数量累加提交订单勾选商品后结算库存扣减、订单生成、购物车对应条目清空支付回调模拟支付成功订单 pay_status 从 0 变为 1记录支付时间取消订单未支付订单取消pay_status 变为 3库存回补每一项验证完后记录结果这是答辩时最实在的过程材料。特别关注取消订单时的库存回补逻辑这是很多课设会漏掉的细节。6.2 并发正确性验证同时下单不超卖并发验证用最简单的办法写一个 Python 脚本开 20 个线程同时抢购同一件库存为 10 的商品看最终生成多少订单、剩余多少库存。这个脚本本身很简单关键是验证结果import threading import urllib.request url http://127.0.0.1:8080/order/submit?productId1001quantity1 def buy(): try: urllib.request.urlopen(url, timeout5) except Exception: pass threads [threading.Thread(targetbuy) for _ in range(20)] for t in threads: t.start() for t in threads: t.join()跑完后查数据库orders 表里该商品的订单数加上 inventory 表的剩余库存必须等于初始库存 10多一单少一单都说明事务边界或锁逻辑有问题。反复跑三次结果一致才算通过。这个验证在答辩现场展示时直观且可信能够直接证明方案具备应对高并发的基础能力。6.3 答辩讲解把设计决策讲成亮点答辩时不需要背表结构重点是讲清楚「为什么这么设计」。三个必讲的问题为什么订单明细冗余商品名称和价格快照因为商品信息会变历史订单必须展示下单时的快照为什么不用物理外键因为高并发下物理外键的额外锁校验会成为瓶颈逻辑外键由应用层控制更灵活为什么库存表单独拆出来并加版本号因为库存是高频更新字段独立成表并配合乐观锁能降低锁冲突范围。最后收个尾讲一次真实的教训之前 A同学做第一个版本时把库存放在商品表里用 SELECT 判断再 UPDATE演示直接翻车库存变成负数。从那以后我每次做数据库设计都会强制把「并发写入的防重、防超卖」作为第一优先级去验证先解决最恶劣的情况再谈查询优化。这套购物网站数据库设计方案的每一张表、每一个索引都是围绕这条主线展开的希望能帮你把课设或毕设做得更扎实顺利通过验收。本文还有配套的精品资源点击获取