商品详情表设计要预留扩展字段，别只存基础信息
电商商品详情往往包含多语言描述、富文本规格、视频链接、参数表格等动态内容，硬编码字段很快会不够用。建议用
JSON类型字段（MySQL 5.7+）或单独的
product_attributes关联表来承载非结构化属性。
常见错误是把所有详情塞进一个
descriptionTEXT 字段，导致后续无法按“是否支持防水”“电池容量”等条件筛选，也无法做全文检索优化。
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 更有效。
