简介这是一份聚焦基于商品属性的电子商务系统研究的PPT演示文稿面向电子商务从业者、系统设计人员及学术研究者核心探讨如何通过属性规范化、属性分类、属性搜索与个性化推荐来优化电商平台。资源为单个pptx文件压缩包仅1.77MB便于快速下载与浏览目前已有73人学习。内容完整覆盖商品属性数据库构建、智能搜索引擎开发、推荐算法优化等实现方案并包含商品分类、属性搜索、购买与分享等功能设计以及系统响应时间、网站性能、数据库性能等测试环节。尤其适合刚接触电商系统设计的学生或需要借鉴系统架构思路的产品经理与开发人员可从中获取基于商品属性的系统设计原则、落地实现路径以及未来在用户隐私保护、交易安全性、系统稳定性等方面的改进方向为相关项目提供结构化参考。1. 商品属性建模为什么它是电子商务系统的“物理定律”“基于商品属性的电子商务系统”听起来像是一道课程设计或毕业答辩的题目但它背后藏着一个非常现实的问题同一个商品为什么在你眼里是“红色 32码 棉质”在系统里却变成几十行很难维护的记录如果你打算照着这个标题做一套可演示、可答辩、甚至能外包给中小商家用的系统商品属性不是“字段怎么填”的细枝末节而是决定整个系统能不能扩展的命门。先给一句反直觉的结论90% 的团队第一次做电商后台时都会把商品属性直接做成数据库表里的十几个列然后在新品类的第一周就返工。因为“连衣裙”需要颜色和尺码“手机”需要内存和屏幕尺寸“大米”需要产地和重量——这些属性完全不在同一个维度上强行用固定列存换品类等于改表结构改表结构等于推倒重来。所以这个标题真正要解决的是一套能容纳任意品类、任意属性组合、还能支持搜索与 SKU 生成的数据结构加上能跑通的前后端流程。本文会把这套方案拆成可复现的步骤先讲类目与属性的关系怎么设计再落到 MySQL 的表结构和 Java 侧的实现最后给出一份能直接拿去判分的项目骨架。新手按步骤走能跑通 demo熟手可以直接跳到第 6 章看性能验证和细节边界。2. 从商品实体到属性体系先分清“类目”和“属性”再动手2.1 为什么不能给每件商品拍脑袋设计十几个字段很多人理解商品第一反应是“商品 名称 价格 库存 图片”然后把这些字段画进一张表里。但电子商务系统里真正要支撑的业务动作是搜索、筛选、下单、库存管理每一个动作都需要不同的商品信息切面搜索用户搜“纯棉 长袖”系统要在几毫秒内知道哪些商品具备“材质”和“袖长”这两个属性筛选用户在类目页勾选“红色”和“32码”系统要把符合条件的 SKU 直接列出来下单用户在详情页选“红色 32码”确定的是一个精确到规格库存的 SKU而不是整件商品库存管理运营要按“每个尺码分别补货多少”必须按 SKU 维度做库存扣减。这些业务动作同时要求商品信息既能“纵向比较”也能“横向扩展”。纵向比较代表同一类目下的商品可以被同一个属性维度筛选比如所有手机都用“内存”来筛横向扩展代表新增品类时不能改动已有数据结构。想要同时满足这两点就必须把商品拆成“类目—属性—属性值”三层来建模。2.2 属性要拆成“关键属性”和“销售属性”这是 SKU 生成的前提商品属性在电商域里有更细的分工落到数据库设计上通常分成两组关键属性也叫非销售属性描述商品是什么。例如手机的“屏幕尺寸”“电池容量”衣服的“材质”“版型”。这类属性影响筛选条件但用户下单时不需要针对它做选择销售属性决定用户“买的是哪一个具体东西”。例如衣服的“颜色”“尺码”手机的“内存”“颜色”。销售属性的每个组合值在库存逻辑里就是一个 SKU。这个拆分的价值在于当你在设计商品发布表单时可以选择哪些属性参与生成 SKU哪些属性只做展示。后面的数据表设计会把这个决策落到字段上。很多项目把销售属性和关键属性混在一起存最后做购物车时无法确定用户选中的是哪一条库存记录天然就做不出“按规格加入购物车”的功能。2.3 类目体系的核心设计三级分类与属性继承实际电商系统里类目通常做成树形常用的深度是三级。一级类目如“服装”二级类目如“男装”三级类目如“T恤”。属性通常挂在三级类目上但一级和二级类目有时也需要一些全局属性比如“适用季节”这时候有两种常见方案方案 A属性表直接挂在三个层级的类目上查询时逐级向上取并集方案 B属性只挂在最末级类目上上级类目的属性由下级合并汇总。方案 A 更常用因为它可以单独为“服装”这个一级类目配置“季节属性”而不必在每个二级类目里重复配置。要注意的是这个设计会带来查询时“属性从哪里来”的问题所以实现时一般会在内存里做一次类目属性缓存避免每加载一个类目页面就打三次数据库。3. 数据表设计五张核心表和一份 E-R 关系的落地写法3.1 基础表结构分类表、属性表、属性值表的拆分属性体系在关系型数据库里最稳妥的落法是这五张表表名作用核心字段category类目表树形结构id, parent_id, name, levelattribute属性定义表挂在类目下id, category_id, name, type1关键属性 2销售属性input_type1单选 2多选 3自定义attribute_value预置属性值表可选项id, attr_id, valueproduct商品表SPUid, category_id, title, subtitle, statusproduct_attr商品属性关联表id, product_id, attr_id, attr_valuesku单品表SKUid, product_id, sku_code, price, stocksku_attrSKU 属性关联表id, sku_id, attr_id, attr_value前五张表解决的是“定义”和“描述”两个层面的存储问题后两张表解决“销售规格与库存”的问题。关键点在于 product_attr 和 sku_attr 都采用 EAVEntity-Attribute-Value结构每一行是一条独立的属性记录而不是一个字段。这是 EAV 模型在电商场景的标准迁移牺牲一点查询直白性换来的是“加属性不动代码”的能力。3.2 用一条 SQL 演示属性查询的常见写法以下演示关键属性筛选场景查“所有屏幕尺寸包含 6.1 英寸的手机”。-- 查关键属性筛选先定位属性 ID再通过 JOIN 找出所有满足条件的 SPU SELECT DISTINCT p.id, p.title FROM product p JOIN product_attr pa ON pa.product_id p.id WHERE p.category_id (SELECT id FROM category WHERE name 手机) AND pa.attr_id (SELECT id FROM attribute WHERE name 屏幕尺寸 AND category_id 2) AND pa.attr_value 6.1英寸;逻辑说明属性 ID 对内层查询不敏感考虑到性能建议在应用里一次查出属性 ID 和类目路径然后放到缓存里避免在 SQL 里反复写子查询。参数attr_value是字符串精确匹配实际项目中屏幕尺寸这类数值型属性最好再单独存一个attr_value_num字段排序时转字符串会出现“10 9”的错误。3.3 渐进式建表先跑通 SPU 属性再补 SKU 的 SQL 脚本虽然最终要的是一整套表结构但开发和演示时别一次建全。建议分三步走第一步建立类目与属性定义表CREATE TABLE category ( id INT PRIMARY KEY AUTO_INCREMENT, parent_id INT DEFAULT 0, name VARCHAR(50) NOT NULL, level TINYINT NOT NULL DEFAULT 1, sort_order INT DEFAULT 0 ); CREATE TABLE attribute ( id INT PRIMARY KEY AUTO_INCREMENT, category_id INT NOT NULL COMMENT 所属类目ID, name VARCHAR(50) NOT NULL COMMENT 属性名如颜色, type TINYINT NOT NULL COMMENT 1关键属性 2销售属性, input_type TINYINT NOT NULL DEFAULT 1 COMMENT 1单选 2多选 3自定义, UNIQUE KEY uk_cat_attr (category_id, name) );参数说明type1的关键属性不进入 SKU 生成type2销售属性后续会被笛卡尔积算出全部规格组合。UNIQUE KEY uk_cat_attr是为了防止同一类目下出现重名属性导致前端拿到重复筛选项。第二步建立商品与属性值表CREATE TABLE product ( id INT PRIMARY KEY AUTO_INCREMENT, category_id INT NOT NULL, title VARCHAR(200) NOT NULL, status TINYINT DEFAULT 1 COMMENT 1上架 0下架, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE product_attr ( id INT PRIMARY KEY AUTO_INCREMENT, product_id INT NOT NULL, attr_id INT NOT NULL, attr_value VARCHAR(100) NOT NULL, UNIQUE KEY uk_pid_attr (product_id, attr_id) );逻辑说明product_attr 里没有直接存属性名而是存attr_id这样属性改名时不需要更新商品数据。UNIQUE KEY uk_pid_attr保证了一个 SPU 下同一个属性只能有一个值——这个约束在“多选属性”场景会有问题所以多选属性要以attr_value LIKE %值%的方式合并存储否则需要拆成多行前端展示会变复杂。这里推荐一个常规做法多选属性值用 JSON 数组字符串存入attr_value搜索时配合JSON_CONTAINS处理。第三步建立 SKU 与 SKU 属性关联表CREATE TABLE sku ( id INT PRIMARY KEY AUTO_INCREMENT, product_id INT NOT NULL, sku_code VARCHAR(50) NOT NULL COMMENT 商家编码, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0 ); CREATE TABLE sku_attr ( id INT PRIMARY KEY AUTO_INCREMENT, sku_id INT NOT NULL, attr_id INT NOT NULL, attr_value VARCHAR(100) NOT NULL, UNIQUE KEY uk_sku_attr (sku_id, attr_id) );sku_attr是连接销售属性和 SKU 的关键桥表。加入购物车时前端提交的是 sku_id 或销售属性值的组合后台通过sku_attr反查 sku_id然后读 sku 表的 stock 判断库存。注意UNIQUE KEY uk_sku_attr确保一个 SKU 下每个销售属性有且只有一个值这也符合“红色 32 码”这种直觉表达。4. 商品发布与 SKU 生成从表单到数据库的完整代码路径4.1 属性渲染动态表单的核心逻辑通过属性定义表驱动前端表单是一个常见的成熟方案后端只负责把这类配置返回给前端由前端动态渲染控件。我们用一段简化的 Java/TypeScript 思路来描述这个设计// 模拟后端返回的属性配置type 决定前端控件类型 const attrConfig [ { attrId: 101, name: 颜色, type: sales, inputType: select, options: [红, 白] }, { attrId: 102, name: 尺码, type: sales, inputType: select, options: [M, L] }, { attrId: 103, name: 材质, type: key, inputType: select, options: [棉, 麻] }, ]; // 前端过滤出销售属性动态渲染下拉框 const salesAttrs attrConfig.filter(attr attr.type sales); document.querySelector(#sku-config).innerHTML salesAttrs .map(attr label${attr.name}/label select>// 输入LinkedHashMap属性ID, 属性值的List保持属性顺序 public ListListString generateSkuCombinations(LinkedHashMapLong, ListString salesAttrMap) { ListListString result new ArrayList(); ListMap.EntryLong, ListString entries new ArrayList(salesAttrMap.entrySet()); backtrack(entries, 0, new ArrayList(), result); return result; } private void backtrack(ListMap.EntryLong, ListString entries, int index, ListString path, ListListString result) { if (index entries.size()) { result.add(new ArrayList(path)); return; } for (String value : entries.get(index).getValue()) { path.add(value); // 下一层递归处理下一个销售属性 backtrack(entries, index 1, path, result); path.remove(path.size() - 1); // 回溯撤销选择 } }参数说明LinkedHashMap必须保证有序否则同一组属性值可能会在生成时产生不同的顺序影响后续 SKU 展示的一致性。entries.get(index)表示按属性顺序取当前属性循环它的全部值递归下去就把每个销售属性的每个值组合了一遍这就是笛卡尔积的通用回溯写法没有任何魔法。4.3 商品发布事务控制先存 SPU再存属性最后存 SKU商品发布是典型的多步写入SPU 没存成功属性和 SKU 绝不能保存。实际项目中可以这样组织事务逻辑Transactional(rollbackFor Exception.class) public Long publishProduct(ProductPublishDTO dto) { // 1. 保存 SPU 主记录得到 productId Product product new Product(); product.setCategoryId(dto.getCategoryId()); product.setTitle(dto.getTitle()); productMapper.insert(product); // 2. 保存关键属性非销售属性 for (AttrItem item : dto.getKeyAttrs()) { ProductAttr pa new ProductAttr(); pa.setProductId(product.getId()); pa.setAttrId(item.getAttrId()); pa.setAttrValue(item.getValue()); productAttrMapper.insert(pa); } // 3. 用笛卡尔积生成 SKU 列表批量插入 ListListString combinations generateSkuCombinations(dto.getSalesAttrMap()); for (ListString combo : combinations) { Sku sku new Sku(); sku.setProductId(product.getId()); sku.setPrice(dto.getPrice()); sku.setStock(0); // 初始库存为 0审核后补库存 skuMapper.insert(sku); // 再把 combo 里的每个值关联到 sku_attr for (int i 0; i combo.size(); i) { SkuAttr sa new SkuAttr(); sa.setSkuId(sku.getId()); sa.setAttrId(dto.getSalesAttrOrder().get(i)); sa.setAttrValue(combo.get(i)); skuAttrMapper.insert(sa); } } return product.getId(); }这个事务如果中途失败注解会回滚所有步骤。值得注意两个细节initialStock0是安全做法SKU 先建出来但不直接公开库存等运营人工确认价格后统一同步避免自动生成时把尚未明确价格的 SKU 直接放出去dto.getSalesAttrOrder()与笛卡尔积的生成顺序保持一致否则sku_attr关联时会张冠李戴。最简单的方式是生成组合前把这个有序属性 ID 列表单独传一份。4.4 商品列表页与筛选项高频查询列表页需要做两件事显示商品基本信息 显示每个商品的属性摘要。属性摘要的数据来源是 product_attr如果真实电商系统里直接在列表页逐条查 product_attr会产生 N1 查询问题。常规做法是查出商品 ID 列表后一次性批量查属性SELECT pa.product_id, pa.attr_value, a.name FROM product_attr pa JOIN attribute a ON a.id pa.attr_id WHERE pa.product_id IN (1, 2, 3, 4, 5) ORDER BY pa.product_id, a.sort_order;这段 SQL 拿到的是商品 ID 到属性值的映射集合内存里按 product_id 分组后再装进列表 DTO。如果强调演示效果也可以直接把属性摘要冗余到商品表的一张product_extra里但那样会引入数据同步成本小项目按批量查询做就够了。5. 商品属性系统避坑指南5 个高频翻车场景与诊断过程5.1 属性值都变成字符串数字排序和范围筛选会怪现象茶叶按“重量 250g/500g/1000g”筛选时排序结果变成 1000、250、500数值范围筛选也失效。原因属性值被设计成了VARCHAR数据库按字典序排序“1000”会在“250”前面。范围筛选拆不出数值。解决在product_attr表上额外加一个attr_value_num DECIMAL(12,2) NULL字段数值型属性的值同时写入字符串和数字列查询时优先用数字列做范围条件。实际情况里也可以用CAST(attr_value AS DECIMAL)临时转换但会丢掉索引数据量过千就该考虑冗余字段。这是最容易在代码评审阶段被翻车的隐患。5.2 多选属性被当成单选存储筛选结果丢失产品现象商品“适用季节”勾选了“春秋”和“夏”结果筛选“夏”时搜不到这个商品。原因product_attr 按UNIQUE KEY uk_pid_attr设计同一个属性的多值只能存一行就会用字符串叠加搜索匹配时直接匹配不到。解决多选属性统一约定存 JSON 数组搜索条件用JSON_CONTAINS(attr_value, 夏, $)查询或者干脆把多选属性设计成“支持重复行”去掉主键唯一约束让同一个商品的同一个属性出现多行查询时判定条件为 “存在一行值等于目标”。两种方案没有绝对优劣但必须全项目统一口径。5.3 类目属性缓存没做失效策略运营改完看不到现象运营在后台给“手机”类目新增了“快充功率”前台类目页刷新后仍然没有这个筛选项。原因类目属性被缓存到 Redis 或本地堆内存缓存 key 只有category_id更新属性后没有主动删除缓存TTL 也没到。解决写属性更新接口时同时执行“更新数据库 删除缓存 key”而不是只更新数据库。习惯上用“先删缓存再更新 DB”会有一个极小概率的并发窗口推荐“先更新 DB再删缓存”并且删除后要允许一次缓存穿透去 DB 重建。加一句口诀式的记忆缓存只能删不能更新。因为属性变化少见但一旦更新旧缓存会让运营觉得系统坏了。5.4 SKU 组合顺序不一致购物车总匹配到错误规格现象同一商品 A 和 B 都有属性“颜色/尺码”A 的 SKU 组合顺序是“红-M红-L”B 的顺序变成“M-红L-红”用户加入 A 购物车后无法正常聚合。原因生成 SKU 组合的代码使用了 HashMap 而不是 LinkedHashMapHashMap 迭代顺序不稳定。解决生成组合时固定用LinkedHashMap并且按类目属性配置的 sort_order 排序后再传入。前端在创建 SKU 组合时也要按下拉框的顺序组合参数不能按用户点击顺序。实际操作里前端很容易把用户“先选尺码再选颜色”的顺序传上来后端就跟着乱了所以要约定一个属性顺序字段。5.5 商品删除走物理删订单和历史记录全断链现象商品下架 3 个月后运营直接删了 product 表历史订单详情页打不开。原因物理删除商品时sku 表和 sku_attr 表虽然通过外键关联但订单明细里存的是 sku_id商品没了、sku 表记录也没了历史数据全部失效。解决商品删除改成逻辑删除给 product 表加is_deleted TINYINT DEFAULT 0字段删除只置 1查询所有业务接口强制拼接is_deleted0。历史订单如果只查订单明细表则不必关心商品是否被删因为价格、快照、图片都是下单时冗余进去的。如果系统真的必须物理删除就先把 sku 表数据和订单表数据做关联校验有订单引用的用户不能执行删除操作。6. 压测与验收技巧用一条 SQL 验证属性体系的扩展性这一章练一个实用技巧怎么在半小时内判断你搭的系统是“能跑 demo”还是“能扛住三轮答辩追问”。一个很管用的办法是对product_attr做一次大数据量压测观察属性查询在百万级 EAV 数据下的表现。压测场景构造先灌入 5000 个 SPU、50 个类目、每个 SPU 平均 15 个属性然后执行下面的筛选查询-- 用 JOIN 代替子查询MySQL 8.0 会自动优化但 5.7 建议主动展开 SELECT SQL_NO_CACHE COUNT(*) FROM product_attr pa JOIN attribute a ON a.id pa.attr_id JOIN product p ON p.id pa.product_id WHERE a.category_id 2 AND a.name 屏幕尺寸 AND pa.attr_value 6.1英寸 AND p.status 1;这个查询的瓶颈在attr_value上做了字符串等值匹配指标是耗时。如果超过 1.2 秒先检查attribute(name, category_id)的唯一索引是否存在再检查是否可在product_attr上加一个组合索引(attr_id, attr_value)。注意别走偏也不要上来就加product_attr(attr_id, attr_value, product_id)这种覆盖索引因为 index 不是越宽越好覆盖列越多插入越慢。另一个更贴近实际答辩的验证随机挑一个新类目“智能手表”手动在 attribute 表里插入“表盘形状”和“续航时长”两个属性再发布一个商品带这两个新属性。如果全程不需要改 Java 代码或数据库表结构说明你的属性体系扩展性成立如果要回到配置文件里新增枚举值说明属性定义和业务代码耦合了需要重构。我在做类似的系统时吃过一次亏把“属性名”直接写死进 Java 常量前端筛选项列表虽然能自定义属性名但后端的搜索逻辑遇到新属性就进不了分支。后来彻底改成“属性名驱动索引”所有属性统一进入一个键值对查询入口才真正做到了“加属性不加代码”。建议你给系统加一个“属性日志”观察表每次属性变更都记录是哪个账号在哪个类目下进行的这招在答辩和后续维护里都非常管用。如果在性能上遇到瓶颈常规做法是等值筛选量特别大时给attr_value建前缀索引或者引入搜索引擎做属性倒排索引但那是后话——先确保主流程跑通再回头优化。上面的建表逻辑和代码骨架已经能支撑你想研究的大多数电子商务系统场景剩下的细节就在一次次调试里慢慢补齐。希望帮到你。本文还有配套的精品资源点击获取
商品属性建模与SKU生成：电商系统的扩展性核心
简介这是一份聚焦基于商品属性的电子商务系统研究的PPT演示文稿面向电子商务从业者、系统设计人员及学术研究者核心探讨如何通过属性规范化、属性分类、属性搜索与个性化推荐来优化电商平台。资源为单个pptx文件压缩包仅1.77MB便于快速下载与浏览目前已有73人学习。内容完整覆盖商品属性数据库构建、智能搜索引擎开发、推荐算法优化等实现方案并包含商品分类、属性搜索、购买与分享等功能设计以及系统响应时间、网站性能、数据库性能等测试环节。尤其适合刚接触电商系统设计的学生或需要借鉴系统架构思路的产品经理与开发人员可从中获取基于商品属性的系统设计原则、落地实现路径以及未来在用户隐私保护、交易安全性、系统稳定性等方面的改进方向为相关项目提供结构化参考。1. 商品属性建模为什么它是电子商务系统的“物理定律”“基于商品属性的电子商务系统”听起来像是一道课程设计或毕业答辩的题目但它背后藏着一个非常现实的问题同一个商品为什么在你眼里是“红色 32码 棉质”在系统里却变成几十行很难维护的记录如果你打算照着这个标题做一套可演示、可答辩、甚至能外包给中小商家用的系统商品属性不是“字段怎么填”的细枝末节而是决定整个系统能不能扩展的命门。先给一句反直觉的结论90% 的团队第一次做电商后台时都会把商品属性直接做成数据库表里的十几个列然后在新品类的第一周就返工。因为“连衣裙”需要颜色和尺码“手机”需要内存和屏幕尺寸“大米”需要产地和重量——这些属性完全不在同一个维度上强行用固定列存换品类等于改表结构改表结构等于推倒重来。所以这个标题真正要解决的是一套能容纳任意品类、任意属性组合、还能支持搜索与 SKU 生成的数据结构加上能跑通的前后端流程。本文会把这套方案拆成可复现的步骤先讲类目与属性的关系怎么设计再落到 MySQL 的表结构和 Java 侧的实现最后给出一份能直接拿去判分的项目骨架。新手按步骤走能跑通 demo熟手可以直接跳到第 6 章看性能验证和细节边界。2. 从商品实体到属性体系先分清“类目”和“属性”再动手2.1 为什么不能给每件商品拍脑袋设计十几个字段很多人理解商品第一反应是“商品 名称 价格 库存 图片”然后把这些字段画进一张表里。但电子商务系统里真正要支撑的业务动作是搜索、筛选、下单、库存管理每一个动作都需要不同的商品信息切面搜索用户搜“纯棉 长袖”系统要在几毫秒内知道哪些商品具备“材质”和“袖长”这两个属性筛选用户在类目页勾选“红色”和“32码”系统要把符合条件的 SKU 直接列出来下单用户在详情页选“红色 32码”确定的是一个精确到规格库存的 SKU而不是整件商品库存管理运营要按“每个尺码分别补货多少”必须按 SKU 维度做库存扣减。这些业务动作同时要求商品信息既能“纵向比较”也能“横向扩展”。纵向比较代表同一类目下的商品可以被同一个属性维度筛选比如所有手机都用“内存”来筛横向扩展代表新增品类时不能改动已有数据结构。想要同时满足这两点就必须把商品拆成“类目—属性—属性值”三层来建模。2.2 属性要拆成“关键属性”和“销售属性”这是 SKU 生成的前提商品属性在电商域里有更细的分工落到数据库设计上通常分成两组关键属性也叫非销售属性描述商品是什么。例如手机的“屏幕尺寸”“电池容量”衣服的“材质”“版型”。这类属性影响筛选条件但用户下单时不需要针对它做选择销售属性决定用户“买的是哪一个具体东西”。例如衣服的“颜色”“尺码”手机的“内存”“颜色”。销售属性的每个组合值在库存逻辑里就是一个 SKU。这个拆分的价值在于当你在设计商品发布表单时可以选择哪些属性参与生成 SKU哪些属性只做展示。后面的数据表设计会把这个决策落到字段上。很多项目把销售属性和关键属性混在一起存最后做购物车时无法确定用户选中的是哪一条库存记录天然就做不出“按规格加入购物车”的功能。2.3 类目体系的核心设计三级分类与属性继承实际电商系统里类目通常做成树形常用的深度是三级。一级类目如“服装”二级类目如“男装”三级类目如“T恤”。属性通常挂在三级类目上但一级和二级类目有时也需要一些全局属性比如“适用季节”这时候有两种常见方案方案 A属性表直接挂在三个层级的类目上查询时逐级向上取并集方案 B属性只挂在最末级类目上上级类目的属性由下级合并汇总。方案 A 更常用因为它可以单独为“服装”这个一级类目配置“季节属性”而不必在每个二级类目里重复配置。要注意的是这个设计会带来查询时“属性从哪里来”的问题所以实现时一般会在内存里做一次类目属性缓存避免每加载一个类目页面就打三次数据库。3. 数据表设计五张核心表和一份 E-R 关系的落地写法3.1 基础表结构分类表、属性表、属性值表的拆分属性体系在关系型数据库里最稳妥的落法是这五张表表名作用核心字段category类目表树形结构id, parent_id, name, levelattribute属性定义表挂在类目下id, category_id, name, type1关键属性 2销售属性input_type1单选 2多选 3自定义attribute_value预置属性值表可选项id, attr_id, valueproduct商品表SPUid, category_id, title, subtitle, statusproduct_attr商品属性关联表id, product_id, attr_id, attr_valuesku单品表SKUid, product_id, sku_code, price, stocksku_attrSKU 属性关联表id, sku_id, attr_id, attr_value前五张表解决的是“定义”和“描述”两个层面的存储问题后两张表解决“销售规格与库存”的问题。关键点在于 product_attr 和 sku_attr 都采用 EAVEntity-Attribute-Value结构每一行是一条独立的属性记录而不是一个字段。这是 EAV 模型在电商场景的标准迁移牺牲一点查询直白性换来的是“加属性不动代码”的能力。3.2 用一条 SQL 演示属性查询的常见写法以下演示关键属性筛选场景查“所有屏幕尺寸包含 6.1 英寸的手机”。-- 查关键属性筛选先定位属性 ID再通过 JOIN 找出所有满足条件的 SPU SELECT DISTINCT p.id, p.title FROM product p JOIN product_attr pa ON pa.product_id p.id WHERE p.category_id (SELECT id FROM category WHERE name 手机) AND pa.attr_id (SELECT id FROM attribute WHERE name 屏幕尺寸 AND category_id 2) AND pa.attr_value 6.1英寸;逻辑说明属性 ID 对内层查询不敏感考虑到性能建议在应用里一次查出属性 ID 和类目路径然后放到缓存里避免在 SQL 里反复写子查询。参数attr_value是字符串精确匹配实际项目中屏幕尺寸这类数值型属性最好再单独存一个attr_value_num字段排序时转字符串会出现“10 9”的错误。3.3 渐进式建表先跑通 SPU 属性再补 SKU 的 SQL 脚本虽然最终要的是一整套表结构但开发和演示时别一次建全。建议分三步走第一步建立类目与属性定义表CREATE TABLE category ( id INT PRIMARY KEY AUTO_INCREMENT, parent_id INT DEFAULT 0, name VARCHAR(50) NOT NULL, level TINYINT NOT NULL DEFAULT 1, sort_order INT DEFAULT 0 ); CREATE TABLE attribute ( id INT PRIMARY KEY AUTO_INCREMENT, category_id INT NOT NULL COMMENT 所属类目ID, name VARCHAR(50) NOT NULL COMMENT 属性名如颜色, type TINYINT NOT NULL COMMENT 1关键属性 2销售属性, input_type TINYINT NOT NULL DEFAULT 1 COMMENT 1单选 2多选 3自定义, UNIQUE KEY uk_cat_attr (category_id, name) );参数说明type1的关键属性不进入 SKU 生成type2销售属性后续会被笛卡尔积算出全部规格组合。UNIQUE KEY uk_cat_attr是为了防止同一类目下出现重名属性导致前端拿到重复筛选项。第二步建立商品与属性值表CREATE TABLE product ( id INT PRIMARY KEY AUTO_INCREMENT, category_id INT NOT NULL, title VARCHAR(200) NOT NULL, status TINYINT DEFAULT 1 COMMENT 1上架 0下架, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE product_attr ( id INT PRIMARY KEY AUTO_INCREMENT, product_id INT NOT NULL, attr_id INT NOT NULL, attr_value VARCHAR(100) NOT NULL, UNIQUE KEY uk_pid_attr (product_id, attr_id) );逻辑说明product_attr 里没有直接存属性名而是存attr_id这样属性改名时不需要更新商品数据。UNIQUE KEY uk_pid_attr保证了一个 SPU 下同一个属性只能有一个值——这个约束在“多选属性”场景会有问题所以多选属性要以attr_value LIKE %值%的方式合并存储否则需要拆成多行前端展示会变复杂。这里推荐一个常规做法多选属性值用 JSON 数组字符串存入attr_value搜索时配合JSON_CONTAINS处理。第三步建立 SKU 与 SKU 属性关联表CREATE TABLE sku ( id INT PRIMARY KEY AUTO_INCREMENT, product_id INT NOT NULL, sku_code VARCHAR(50) NOT NULL COMMENT 商家编码, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0 ); CREATE TABLE sku_attr ( id INT PRIMARY KEY AUTO_INCREMENT, sku_id INT NOT NULL, attr_id INT NOT NULL, attr_value VARCHAR(100) NOT NULL, UNIQUE KEY uk_sku_attr (sku_id, attr_id) );sku_attr是连接销售属性和 SKU 的关键桥表。加入购物车时前端提交的是 sku_id 或销售属性值的组合后台通过sku_attr反查 sku_id然后读 sku 表的 stock 判断库存。注意UNIQUE KEY uk_sku_attr确保一个 SKU 下每个销售属性有且只有一个值这也符合“红色 32 码”这种直觉表达。4. 商品发布与 SKU 生成从表单到数据库的完整代码路径4.1 属性渲染动态表单的核心逻辑通过属性定义表驱动前端表单是一个常见的成熟方案后端只负责把这类配置返回给前端由前端动态渲染控件。我们用一段简化的 Java/TypeScript 思路来描述这个设计// 模拟后端返回的属性配置type 决定前端控件类型 const attrConfig [ { attrId: 101, name: 颜色, type: sales, inputType: select, options: [红, 白] }, { attrId: 102, name: 尺码, type: sales, inputType: select, options: [M, L] }, { attrId: 103, name: 材质, type: key, inputType: select, options: [棉, 麻] }, ]; // 前端过滤出销售属性动态渲染下拉框 const salesAttrs attrConfig.filter(attr attr.type sales); document.querySelector(#sku-config).innerHTML salesAttrs .map(attr label${attr.name}/label select>// 输入LinkedHashMap属性ID, 属性值的List保持属性顺序 public ListListString generateSkuCombinations(LinkedHashMapLong, ListString salesAttrMap) { ListListString result new ArrayList(); ListMap.EntryLong, ListString entries new ArrayList(salesAttrMap.entrySet()); backtrack(entries, 0, new ArrayList(), result); return result; } private void backtrack(ListMap.EntryLong, ListString entries, int index, ListString path, ListListString result) { if (index entries.size()) { result.add(new ArrayList(path)); return; } for (String value : entries.get(index).getValue()) { path.add(value); // 下一层递归处理下一个销售属性 backtrack(entries, index 1, path, result); path.remove(path.size() - 1); // 回溯撤销选择 } }参数说明LinkedHashMap必须保证有序否则同一组属性值可能会在生成时产生不同的顺序影响后续 SKU 展示的一致性。entries.get(index)表示按属性顺序取当前属性循环它的全部值递归下去就把每个销售属性的每个值组合了一遍这就是笛卡尔积的通用回溯写法没有任何魔法。4.3 商品发布事务控制先存 SPU再存属性最后存 SKU商品发布是典型的多步写入SPU 没存成功属性和 SKU 绝不能保存。实际项目中可以这样组织事务逻辑Transactional(rollbackFor Exception.class) public Long publishProduct(ProductPublishDTO dto) { // 1. 保存 SPU 主记录得到 productId Product product new Product(); product.setCategoryId(dto.getCategoryId()); product.setTitle(dto.getTitle()); productMapper.insert(product); // 2. 保存关键属性非销售属性 for (AttrItem item : dto.getKeyAttrs()) { ProductAttr pa new ProductAttr(); pa.setProductId(product.getId()); pa.setAttrId(item.getAttrId()); pa.setAttrValue(item.getValue()); productAttrMapper.insert(pa); } // 3. 用笛卡尔积生成 SKU 列表批量插入 ListListString combinations generateSkuCombinations(dto.getSalesAttrMap()); for (ListString combo : combinations) { Sku sku new Sku(); sku.setProductId(product.getId()); sku.setPrice(dto.getPrice()); sku.setStock(0); // 初始库存为 0审核后补库存 skuMapper.insert(sku); // 再把 combo 里的每个值关联到 sku_attr for (int i 0; i combo.size(); i) { SkuAttr sa new SkuAttr(); sa.setSkuId(sku.getId()); sa.setAttrId(dto.getSalesAttrOrder().get(i)); sa.setAttrValue(combo.get(i)); skuAttrMapper.insert(sa); } } return product.getId(); }这个事务如果中途失败注解会回滚所有步骤。值得注意两个细节initialStock0是安全做法SKU 先建出来但不直接公开库存等运营人工确认价格后统一同步避免自动生成时把尚未明确价格的 SKU 直接放出去dto.getSalesAttrOrder()与笛卡尔积的生成顺序保持一致否则sku_attr关联时会张冠李戴。最简单的方式是生成组合前把这个有序属性 ID 列表单独传一份。4.4 商品列表页与筛选项高频查询列表页需要做两件事显示商品基本信息 显示每个商品的属性摘要。属性摘要的数据来源是 product_attr如果真实电商系统里直接在列表页逐条查 product_attr会产生 N1 查询问题。常规做法是查出商品 ID 列表后一次性批量查属性SELECT pa.product_id, pa.attr_value, a.name FROM product_attr pa JOIN attribute a ON a.id pa.attr_id WHERE pa.product_id IN (1, 2, 3, 4, 5) ORDER BY pa.product_id, a.sort_order;这段 SQL 拿到的是商品 ID 到属性值的映射集合内存里按 product_id 分组后再装进列表 DTO。如果强调演示效果也可以直接把属性摘要冗余到商品表的一张product_extra里但那样会引入数据同步成本小项目按批量查询做就够了。5. 商品属性系统避坑指南5 个高频翻车场景与诊断过程5.1 属性值都变成字符串数字排序和范围筛选会怪现象茶叶按“重量 250g/500g/1000g”筛选时排序结果变成 1000、250、500数值范围筛选也失效。原因属性值被设计成了VARCHAR数据库按字典序排序“1000”会在“250”前面。范围筛选拆不出数值。解决在product_attr表上额外加一个attr_value_num DECIMAL(12,2) NULL字段数值型属性的值同时写入字符串和数字列查询时优先用数字列做范围条件。实际情况里也可以用CAST(attr_value AS DECIMAL)临时转换但会丢掉索引数据量过千就该考虑冗余字段。这是最容易在代码评审阶段被翻车的隐患。5.2 多选属性被当成单选存储筛选结果丢失产品现象商品“适用季节”勾选了“春秋”和“夏”结果筛选“夏”时搜不到这个商品。原因product_attr 按UNIQUE KEY uk_pid_attr设计同一个属性的多值只能存一行就会用字符串叠加搜索匹配时直接匹配不到。解决多选属性统一约定存 JSON 数组搜索条件用JSON_CONTAINS(attr_value, 夏, $)查询或者干脆把多选属性设计成“支持重复行”去掉主键唯一约束让同一个商品的同一个属性出现多行查询时判定条件为 “存在一行值等于目标”。两种方案没有绝对优劣但必须全项目统一口径。5.3 类目属性缓存没做失效策略运营改完看不到现象运营在后台给“手机”类目新增了“快充功率”前台类目页刷新后仍然没有这个筛选项。原因类目属性被缓存到 Redis 或本地堆内存缓存 key 只有category_id更新属性后没有主动删除缓存TTL 也没到。解决写属性更新接口时同时执行“更新数据库 删除缓存 key”而不是只更新数据库。习惯上用“先删缓存再更新 DB”会有一个极小概率的并发窗口推荐“先更新 DB再删缓存”并且删除后要允许一次缓存穿透去 DB 重建。加一句口诀式的记忆缓存只能删不能更新。因为属性变化少见但一旦更新旧缓存会让运营觉得系统坏了。5.4 SKU 组合顺序不一致购物车总匹配到错误规格现象同一商品 A 和 B 都有属性“颜色/尺码”A 的 SKU 组合顺序是“红-M红-L”B 的顺序变成“M-红L-红”用户加入 A 购物车后无法正常聚合。原因生成 SKU 组合的代码使用了 HashMap 而不是 LinkedHashMapHashMap 迭代顺序不稳定。解决生成组合时固定用LinkedHashMap并且按类目属性配置的 sort_order 排序后再传入。前端在创建 SKU 组合时也要按下拉框的顺序组合参数不能按用户点击顺序。实际操作里前端很容易把用户“先选尺码再选颜色”的顺序传上来后端就跟着乱了所以要约定一个属性顺序字段。5.5 商品删除走物理删订单和历史记录全断链现象商品下架 3 个月后运营直接删了 product 表历史订单详情页打不开。原因物理删除商品时sku 表和 sku_attr 表虽然通过外键关联但订单明细里存的是 sku_id商品没了、sku 表记录也没了历史数据全部失效。解决商品删除改成逻辑删除给 product 表加is_deleted TINYINT DEFAULT 0字段删除只置 1查询所有业务接口强制拼接is_deleted0。历史订单如果只查订单明细表则不必关心商品是否被删因为价格、快照、图片都是下单时冗余进去的。如果系统真的必须物理删除就先把 sku 表数据和订单表数据做关联校验有订单引用的用户不能执行删除操作。6. 压测与验收技巧用一条 SQL 验证属性体系的扩展性这一章练一个实用技巧怎么在半小时内判断你搭的系统是“能跑 demo”还是“能扛住三轮答辩追问”。一个很管用的办法是对product_attr做一次大数据量压测观察属性查询在百万级 EAV 数据下的表现。压测场景构造先灌入 5000 个 SPU、50 个类目、每个 SPU 平均 15 个属性然后执行下面的筛选查询-- 用 JOIN 代替子查询MySQL 8.0 会自动优化但 5.7 建议主动展开 SELECT SQL_NO_CACHE COUNT(*) FROM product_attr pa JOIN attribute a ON a.id pa.attr_id JOIN product p ON p.id pa.product_id WHERE a.category_id 2 AND a.name 屏幕尺寸 AND pa.attr_value 6.1英寸 AND p.status 1;这个查询的瓶颈在attr_value上做了字符串等值匹配指标是耗时。如果超过 1.2 秒先检查attribute(name, category_id)的唯一索引是否存在再检查是否可在product_attr上加一个组合索引(attr_id, attr_value)。注意别走偏也不要上来就加product_attr(attr_id, attr_value, product_id)这种覆盖索引因为 index 不是越宽越好覆盖列越多插入越慢。另一个更贴近实际答辩的验证随机挑一个新类目“智能手表”手动在 attribute 表里插入“表盘形状”和“续航时长”两个属性再发布一个商品带这两个新属性。如果全程不需要改 Java 代码或数据库表结构说明你的属性体系扩展性成立如果要回到配置文件里新增枚举值说明属性定义和业务代码耦合了需要重构。我在做类似的系统时吃过一次亏把“属性名”直接写死进 Java 常量前端筛选项列表虽然能自定义属性名但后端的搜索逻辑遇到新属性就进不了分支。后来彻底改成“属性名驱动索引”所有属性统一进入一个键值对查询入口才真正做到了“加属性不加代码”。建议你给系统加一个“属性日志”观察表每次属性变更都记录是哪个账号在哪个类目下进行的这招在答辩和后续维护里都非常管用。如果在性能上遇到瓶颈常规做法是等值筛选量特别大时给attr_value建前缀索引或者引入搜索引擎做属性倒排索引但那是后话——先确保主流程跑通再回头优化。上面的建表逻辑和代码骨架已经能支撑你想研究的大多数电子商务系统场景剩下的细节就在一次次调试里慢慢补齐。希望帮到你。本文还有配套的精品资源点击获取
