当前位置：首页 > news >正文

【实战解析】电商后台核心：SPU与SKU分离的数据库架构设计与性能考量

news 2026/6/29 6:17:35

1. 电商后台的基石：SPU与SKU到底是什么？

做过电商开发的朋友一定对这两个概念不陌生，但说实话，我刚入行时也被绕晕过。简单来说，SPU（Standard Product Unit）是标准产品单元，SKU（Stock Keeping Unit）是库存量单位。举个例子，iPhone 13就是一个SPU，而"iPhone 13 256GB 午夜色"就是一个具体的SKU。

在实际项目中，我发现很多团队容易犯一个错误：把SPU和SKU混在一张表里设计。比如早期我们有个服装电商项目，把所有颜色、尺码都作为字段塞进商品表，结果字段爆炸式增长，查询性能直线下降。后来重构时采用了SPU/SKU分离的方案，性能提升了3倍多。

2. 五表设计方案：经典但够用吗？

2.1 基础表结构解析

原始文章提到的五表方案确实能解决大部分中小型电商的需求：

分类表（category）：采用树形结构存储，要注意无限层级带来的递归查询性能问题
SPU表（product）：核心字段是attribute_list，这里用JSON存储所有可变属性
SKU表（product_specs）：关键字段是product_id和product_specs，后者也是JSON
属性键值表（attribute_key/value）：用于后台管理界面生成选项

我在实际使用中发现，这种设计的优势在于：

表结构稳定，新增属性不用改表
前端展示灵活，属性组合自由度高
开发初期快速上线，适合MVP阶段

2.2 JSON字段的甜蜜陷阱

很多团队（包括我们早期）喜欢用JSON字段的"灵活性"，但踩过几次坑后发现：

-- 问题示例：无法直接索引JSON内部字段 SELECT * FROM product_specs WHERE product_specs->>'$.颜色' = '红色'

这种查询在大数据量时性能极差。我们后来在月活百万级的平台上实测，相同查询条件：

直接查JSON字段：平均响应时间1200ms
拆分成独立字段：平均响应时间80ms

提示：如果必须使用JSON字段，至少要在MySQL 8.0+版本，利用函数索引功能创建虚拟列索引

3. 高并发场景下的性能优化实战

3.1 分库分表策略

当SKU表超过500万行时，单表查询已经开始明显变慢。我们采用的方案是：

水平分表：按商品类目分表（如product_specs_electronics）
读写分离：主库写，从库读，注意主从延迟问题
热点数据缓存：用Redis缓存Top 10%的热门SKU

// 伪代码示例：分表路由策略 public String determineTableName(Long categoryId) { if(categoryId >= 1000 && categoryId < 2000) { return "product_specs_electronics"; } // 其他类目判断... }

3.2 索引设计的艺术

一个常见的误区是在所有字段上都建索引。我们曾有个商品表建了15个索引，结果写入性能下降60%。后来优化为：

SPU表：联合索引(category_id, status)
SKU表：联合索引(product_id, status, price)
必须：所有外键字段都要有单列索引

对于JSON字段，如果业务确实需要查询内部属性，可以采用：

-- MySQL 8.0的函数索引方案 ALTER TABLE product_specs ADD COLUMN color VARCHAR(20) GENERATED ALWAYS AS (product_specs->>'$.颜色'), ADD INDEX idx_color (color);

4. 复杂查询的应对之道

4.1 多属性筛选的实现

用户在前端选择"颜色=红+内存=256G"时，传统方案有两种：

应用层过滤：

# 伪代码：先查后过滤 skus = SKU.objects.filter(product_id=123) results = [s for s in skus if s.specs['颜色']=='红' and s.specs['内存']=='256G']

问题：数据量大时内存爆炸

数据库JSON查询：

SELECT * FROM product_specs WHERE product_specs->>'$.颜色'='红' AND product_specs->>'$.内存'='256G'

问题：无法利用索引

我们的解决方案：

使用Elasticsearch建立商品搜索集群
将SKU属性平铺为文档字段
支持毫秒级的多属性组合查询

4.2 实时库存的架构设计

秒杀场景下，库存更新是个大挑战。我们最终采用的方案是：

Redis预扣库存：先扣减Redis中的库存
异步落库：通过消息队列同步到数据库
补偿机制：定时任务核对Redis与DB库存

// 伪代码：库存扣减逻辑 public boolean deductStock(Long skuId, int num) { String key = "stock:" + skuId; long value = redis.decrBy(key, num); if (value >= 0) { mq.send(new StockMessage(skuId, num)); return true; } else { redis.incrBy(key, num); // 回滚 return false; } }

5. 架构演进：从单体到分布式

随着业务量增长，我们经历了三次架构升级：

V1.0：所有表在单一数据库，出现性能瓶颈
V2.0：商品服务独立部署，分库分表
V3.0：引入CQRS模式，将读操作与写操作分离

关键转折点是当SKU数量突破1000万时，我们发现：

商品列表API响应时间从200ms飙升到2s
数据库CPU长期处于90%以上
写操作阻塞读操作

最终的分布式架构核心组件：

写服务：处理商品创建/修改，使用强一致性事务
读服务：基于ES实现搜索，数据最终一致
数据同步：通过CDC捕获数据库变更事件

6. 踩坑经验：那些年我们犯过的错

6.1 过度设计陷阱

早期我们设计了一个"万能"的商品系统：

支持动态添加任意属性
支持无限级分类
支持多维度SKU

结果：

开发周期延长3倍
系统复杂度指数级上升
80%的功能从未被使用

教训：先用简单方案满足核心需求，再逐步扩展

6.2 缓存一致性问题

曾经因为缓存更新策略不当，导致：

商品详情显示库存为10
实际下单时数据库已售罄
引发大量客诉

解决方案：

采用Cache Aside Pattern
设置合理的缓存过期时间
关键操作直接穿透到数据库

# 正确的缓存读取逻辑 def get_sku(sku_id): data = cache.get(f'sku:{sku_id}') if not data: data = db.query_sku(sku_id) cache.set(f'sku:{sku_id}', data, timeout=300) return data