商品详情表需用JSON字段或关联表存动态内容，库存须按仓/渠道分表管理并用日志驱动模式扣减，详情页库存查询应通过消息队列同步至Redis缓存。
商品详情表设计要预留扩展字段，别只存基础信息
电商商品详情往往包含多语言描述、富文本规格、视频链接、参数表格等动态内容，硬编码字段很快会不够用。建议用 JSON 类型字段（MySQL 5.7+）或单独的 product_attributes 关联表来承载非结构化属性。
常见错误是把所有详情塞进一个 description TEXT 字段，导致后续无法按“是否支持防水”“电池容量”等条件筛选，也无法做全文检索优化。
-
products表保留核心字段：id、sku、name、status、created_at - 用
detailsJSON 字段存：主图列表、视频 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 更有效。
