mysql在电子商务平台中的商品详情与库存管理

商品详情表需用jsON字段或关联表存动态内容，库存须按仓/渠道分表管理并用日志驱动模式扣减，详情页库存查询应通过消息队列同步至redis缓存。

商品详情表设计要预留扩展字段，别只存基础信息

电商商品详情往往包含多语言描述、富文本规格、视频链接、参数表格等动态内容，硬编码字段很快会不够用。建议用 json 类型字段（mysql 5.7+）或单独的 product_attributes 关联表来承载非结构化属性。

常见错误是把所有详情塞进一个 description TEXT 字段，导致后续无法按“是否支持防水”“电池容量”等条件筛选，也无法做全文检索优化。

• products 表保留核心字段：id、sku、name、status、created_at
• 用 details JSON 字段存：主图列表、视频 URL、售后政策、包装清单等变长内容
• 关键搜索属性（如 brand、category_id、weight_g）仍需独立列 + 索引

库存必须分仓/分渠道管理，单个 stock 字段会引发超卖

真实电商场景中，“总库存”毫无意义：华东仓有货，华南仓缺货；app 可售，小程序已下架；预售商品和现货不能混算。直接对 products.stock 做 UPDATE ... SET stock = stock - 1 是高危操作。

正确做法是建立 inventory 明细表，粒度到 sku + warehouse_id + channel 组合，并用事务+行锁控制扣减。

• 扣减前先 select ... for UPDATE 锁定对应 inventory 行
• 检查 available_quantity >= order_quantity，不满足则直接失败，不回滚整单
• 成功后更新 available_quantity 和 locked_quantity（用于防重复提交）
• 订单支付失败或超时，需异步释放 locked_quantity

高并发下单时，INSERT INTO inventory_log 比 UPDATE inventory 更可靠

单纯靠 UPDATE 更新库存，在秒杀场景下容易因死锁或间隙锁阻塞导致大量请求失败。改用“日志驱动”模式，把每次扣减当作一条不可逆记录写入 inventory_log，再由后台任务异步聚合更新 inventory.available_quantity。

这样既避免热点行争抢，又保留完整审计链路。只要日志写成功，业务就可返回“已锁定”，后续补偿逻辑兜底。

• inventory_log 必须有唯一索引：(sku, warehouse_id, channel, order_id)
• 聚合任务用 SELECT SUM(change) GROUP BY sku, warehouse_id, channel 计算最新可用量
• 注意处理重复日志（如重试导致的幂等问题），推荐用 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE

查询商品详情时，JOIN inventory 会导致慢，要用缓存隔离读写

用户浏览商品页需要实时库存（如“仅剩3件”），但每次查 products 都 JOIN inventory，在库存表数据量大、索引不当时，会拖垮整个详情接口。数据库不是实时库存显示器。

实际方案是：库存变更写库后，通过消息队列（如 kafka/rocketmq）通知缓存服务，将 sku:available_quantity 写入 redis；详情页直接查 Redis + 主库，失败再降级查库。

• Redis key 建议带版本号，如 inv:v2:10086:shanghai，便于灰度切换逻辑
• 缓存失效不要用定时过期，而应监听 inventory_log 表变更（如用 Canal）主动刷新
• 绝对不要在商品详情 SQL 中加 FOR UPDATE——那是写操作的事，读不该承担锁开销

库存和详情耦合得越紧，系统越难扩容。拆开它们，比调优一条 SQL 更有效。