1. 电商后台的基石SPU与SKU到底是什么做过电商开发的朋友一定对这两个概念不陌生但说实话我刚入行时也被绕晕过。简单来说SPUStandard Product Unit是标准产品单元SKUStock 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_id123) 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(fsku:{sku_id}) if not data: data db.query_sku(sku_id) cache.set(fsku:{sku_id}, data, timeout300) return data7. 未来展望更灵活的商品系统虽然当前架构已经比较成熟但技术总是在发展。最近我们在尝试将部分业务逻辑下放到数据库使用存储过程处理复杂规则试用NewSQL数据库如TiDB解决分库分表带来的事务问题探索GraphQL接口让前端可以自由组合所需字段商品系统作为电商的核心其设计需要平衡灵活性、性能和开发成本。没有最好的方案只有最适合当前业务阶段的方案。每次架构升级都应该以解决实际痛点为出发点而不是盲目追求新技术。