PMS SKU Stock解析

pms_sku_stock 表解析

1. 业务层面理解

pms_sku_stock 表主要用于存储商品 SKU（Stock Keeping Unit，库存单位）的库存信息。在电商系统中，商品（Product）通常有不同的规格（如颜色、尺码等），每个规格组合对应一个 SKU。因此，该表的主要作用是：

• 记录每个 SKU 的库存情况
• 支持库存管理（包括锁定库存、预警库存等）
• 关联商品价格和促销价格
• 追踪 SKU 的销量

在业务流程中，该表通常用于：

• 下单时校验库存
• 订单支付后扣减库存
• 订单取消/退款时释放库存
• 商品详情页展示不同 SKU 价格和库存
• 促销活动中的 SKU 价格调整

---

2. 表字段解析

pms_sku_stock 表的字段如下：

字段名	数据类型	说明
id	bigint(20)	主键，自增
product_id	bigint(20)	关联 pms_product 表，表示该 SKU 属于哪个商品
sku_code	varchar(64)	SKU 编码，唯一标识 SKU
price	decimal(10,2)	SKU 的原价
stock	int(11)	SKU 的可用库存数量
low_stock	int(11)	预警库存，当库存低于该值时，可能会触发预警通知
pic	varchar(255)	SKU 关联的展示图片
sale	int(11)	该 SKU 的销量
promotion_price	decimal(10,2)	SKU 在促销活动中的价格（如果有促销）
lock_stock	int(11)	锁定库存（如：待付款订单锁定的库存，支付完成才扣减）
sp_data	varchar(500)	商品销售属性（JSON 格式），用于描述该 SKU 的规格，如 {"颜色":"红色", "尺码":"L"}

---

3. 该表与其他表的关联

pms_sku_stock 表主要和以下表有外键关系：

1. 商品表 pms_product

   • 通过 product_id 关联，表示该 SKU 属于哪个商品
   • 例如：pms_product 表中可能有 "Nike 运动鞋"，而 pms_sku_stock 可能有 "Nike 运动鞋（黑色，42码）"、"Nike 运动鞋（白色，41码）" 等 SKU

2. 购物车表 oms_cart_item

   • product_sku_id 关联 pms_sku_stock 表的 id
   • 购物车中存储用户添加的具体 SKU 信息
   • 例如：用户在购物车中选择的是 "Nike 运动鞋（黑色，42码）"

3. 订单项表 oms_order_item

   • product_sku_id 关联 pms_sku_stock 表的 id
   • 订单确认后，库存需要锁定并在支付完成后扣减库存
   • 例如：用户下单了一双 "Nike 运动鞋（黑色，42码）"，支付后该 SKU 的 stock 减少 1

4. 促销表 sms_flash_promotion_product_relation

   • product_id 关联 pms_product，并可能涉及 pms_sku_stock
   • 促销活动可能会针对某些 SKU 设置特价，影响 promotion_price 字段

---

4. 业务应用场景

（1）库存管理

• 当用户下单时，先检查 stock 是否足够，再扣减 lock_stock
• 订单支付成功后，真正扣减 stock
• 订单取消或退款时，释放 lock_stock

（2）促销活动

• 促销时，可以更新 promotion_price 字段
• 例如：Nike 运动鞋（黑色，42码） 原价 ¥499，促销价 ¥399

（3）预警通知

• 当 stock 低于 low_stock 时，触发库存预警
• 例如：Nike 运动鞋（黑色，42码） 低于 5 件，通知补货

（4）展示 SKU 信息

• 商品详情页根据 pms_sku_stock 的 sp_data 显示不同规格的 SKU
• 例如："颜色：黑色 / 白色"，"尺码：41 / 42 / 43"

---

5. 总结

• pms_sku_stock 负责管理 SKU 级别的库存、价格、促销等信息
• 该表与 pms_product（商品）、oms_cart_item（购物车）、oms_order_item（订单项）等表紧密相关
• 业务流程中涉及下单、支付、退款、促销等环节
• 通过 lock_stock 机制避免超卖，low_stock 机制实现库存预警

这个表是电商系统中至关重要的库存管理核心，影响整个库存调度和订单履约流程。

在电商后台管理中，pms_sku_stock 里面的字段可能有些在实际场景中使用频率较高，有些则是为更灵活的业务需求做的预留。下面从业务和实际使用层面，分别阐述一下 sku_code、sale、promotion_price、lock_stock 这几个字段的含义与作用。

---

1. sku_code

1.1 字段含义

• 字段类型：varchar(64)（或类似长度）
• 可能的命名：SKU 编码、SKU 标识
• 业务含义：
  sku_code 通常是SKU 在业务或仓储系统中的唯一识别码，用于区分不同的 SKU。
  在一些系统中，sku_code 也会用来与线下或第三方仓储系统进行对接，因为仓库通常使用 SKU 编码来定位和出入库。

1.2 业务场景

1. 仓库对接：
   如果需要将库存数据同步到第三方仓储，或在 ERP（企业资源规划）系统中做出入库、盘点操作，可以通过 sku_code 对应到仓库系统里的 SKU 代码。
2. 商品管理：
   后台或运营人员在搜索某个商品的某个 SKU 时，有时会直接使用 sku_code 进行精确查找。

1.3 注意事项

• sku_code 在同一个商品体系里要保证全局或至少商品维度唯一，否则会造成数据混乱。
• 一般的做法是，在电商平台上对于同一商品的不同规格组合，生成对应的 sku_code。有些公司会用流水号或规则编码自动生成（如 “SKU_商品ID_颜色_尺码_随机码” 之类）。

---

2. sale

2.1 字段含义

• 字段类型：int(11)（或整型）
• 可能的命名：销量、累计销售量
• 业务含义：
  sale 一般代表该 SKU 的累计销售量或销量统计，用于展示、统计或做营销决策。

2.2 业务场景

1. 前台展示：
   一些电商网站会显示 “已售出多少件”，来做销量展示，增加用户购买信心。
2. 销售统计：
   运营或财务人员可能会根据这个字段统计当下最畅销的 SKU，或者对比分析同一个商品不同规格的销量差异。
3. 营销策略：
   • 运营人员可能会优先推广销量较高的 SKU（因为畅销 SKU 通常转化率更好）。
   • 对销量不佳的 SKU 做促销或清仓处理。

2.3 注意事项

• 系统里需要在订单完成后（例如订单状态为已发货、确认收货等），更新或累加该字段，确保统计的真实性。
• 如果订单取消或退款，部分系统也会相应减去销量，具体看业务规则。

---

3. promotion_price

3.1 字段含义

• 字段类型：decimal(10,2)（或类似精度的小数）
• 可能的命名：促销价、活动价格
• 业务含义：
  promotion_price 表示SKU 在促销或活动期间的售价。当有优惠活动时，通常会将商品临时以折扣价对外显示和售卖。

3.2 业务场景

1. 限时折扣：
   在进行限时秒杀或满减促销活动时，将 SKU 的促销价赋值到 promotion_price，前端在活动时间内优先展示 promotion_price 而不是 price。
2. 活动管理：
   不同促销活动的价格可能会写入这个字段。如抢购活动价、拼团价等。不过也有些系统会将促销价放在活动单独的关联表中，根据活动 ID 进行映射，具体根据业务设计而定。
3. 价格显示逻辑：
   • 如果 promotion_price 有值且活动进行中，则页面会显示促销价；若促销结束或 promotion_price 为空，则显示原价 price。
   • 有些平台会显示原价划线价 + 促销价双价展示。

3.3 注意事项

• promotion_price 是否一定要存储在 pms_sku_stock 里，或者存储在哪个促销专用表里，需要结合系统设计考虑。如果活动很多，可能会使用更灵活的方式去记录，而不是直接写在 SKU 表里。
• 注意促销的时间段管理：仅在促销有效期内使用 promotion_price 做交易结算，过期或提前结束后必须恢复原价。

---

4. lock_stock

4.1 字段含义

• 字段类型：int(11)（或整型）
• 可能的命名：锁定库存、占用库存
• 业务含义：
  lock_stock 用于记录正在被“锁定”的库存数量。通常在下单环节或活动预留库存时，会先锁定库存，等真正支付完成后再扣减实际库存。

4.2 业务场景

1. 下单锁库：
   用户在电商平台下单时，如果不立刻支付，在生成订单后，需要从 stock 里扣除一部分放到 lock_stock 中，代表已被这笔订单占用，避免其他用户重复购买导致超卖。
2. 支付/取消：
   • 当订单支付成功，系统会正式减掉库存 stock，并且相应地减少 lock_stock。
   • 如果订单未支付超时取消或用户主动取消，这个订单对应的“锁定库存”就要释放回到 stock 里去。
3. 大促销活动防超卖：
   当有大规模秒杀或预售，锁库逻辑更为关键；秒杀系统一般会通过修改 lock_stock 或其他“占用库存”字段来保障不会超卖。

4.3 注意事项

• 需要与订单状态或支付状态及时联动更新：
  • 下单成功且支付中，先增加 lock_stock；
  • 支付成功后，真正扣减 stock；
  • 订单关闭或支付失败释放 lock_stock。
• 如果系统处理不及时或者并发量大，可能出现“锁库没释放”或“库存没有真正扣减”的问题，需要在业务流程和事务处理上做好设计。

---

5. 总结

• sku_code：SKU 的唯一识别码，便于库存、仓储、订单系统进行对接或定位
• sale：累计销量统计字段，可用于前台展示及后台运营决策
• promotion_price：在促销活动或优惠期间所使用的价格
• lock_stock：订单下单后锁定的库存量，用于防止并发购买时的超卖问题

这四个字段体现了一个电商平台在SKU 管理、库存管理、营销活动管理和销售统计方面的基本需求与流程。在实际开发中，需要结合订单、支付、库存扣减等核心链路，才能让这些字段真正发挥作用。

下面给你一个逐步、场景化的例子，帮你理解实际业务中 lock_stock（锁定库存）是怎么操作的，以及为什么有时会出现看似“奇怪”的数值（例如负数）。

---

一、先看你给出的数据

你给出了两行示例数据（字段取决于你的表结构，以下仅根据你提供的信息做推测）：

id	product_id	sku_code	price	stock	lock_stock	sp_data
98	27	201808270027001	2699.00	86	-24	[{"key":"颜色","value":"黑色"},{"key":"容量","value":"32G"}]
99	27	201808270027002	2999.00	100	0	[{"key":"颜色","value":"黑色"},{"key":"容量","value":"64G"}]

从这儿可以看出两个 SKU（都是 product_id = 27 的同一个商品的不同规格）：

1. SKU1（id=98）：32G，当前 stock=86，lock_stock=-24
2. SKU2（id=99）：64G，当前 stock=100，lock_stock=0

其中，SKU2 的 lock_stock=0 很常见，表示目前没有被下单占用的库存；但 SKU1 出现了 lock_stock=-24，就比较特殊或“诡异”了，按正常逻辑，锁定库存一般不会为负。

我们先简单回顾一下“正常的”锁库流程是什么样的，随后再讨论为什么会出现负数。

---

二、正常锁库流程（理想情况下）

2.1 下单时

1. 用户在前台提交订单：
   • 假设用户要买 3 个“黑色 32G”这个 SKU。
   • 业务逻辑先判断：当前 stock >= 3 吗？如果够，就把这 3 个“暂时锁定”，以防止别人再买走。
2. 更新库存表：
   在订单产生（但还未支付）时，通常会：
   • 增加 lock_stock 的值（+3）
   • 也可以选择同时减少 stock，或者把 stock 保持原样，仅用 lock_stock 来标识“被占用”的量——不同项目对字段意义可能略有差异。
   常见做法是：
   • stock 只记录“可售库存”剩余量，而“锁定库存”用 lock_stock 记录。
   • 或者 stock 记录“理论总库存”，lock_stock 记录已被锁的。无论哪种，都不应该出现负数锁定。
3. 举例：
   • 原来 stock=86, lock_stock=0。
   • 用户买了 3 个，那么锁定 3 个库存：
     • stock 可能保持 86 不变，lock_stock 变成 3；
     • 或者 stock 直接改为 83，lock_stock 变为 3；要看具体项目如何定义字段含义。

2.2 订单支付/取消时

• 支付成功：
  • 在实际业务中，会把“锁定的 3 个”真正从总库存里减掉；如果 stock 在下单时未减过，这时就 stock = 86 - 3 = 83，lock_stock = 0（释放占用）
  • 如果在下单时已经把 stock 减到 83，只是还在 lock_stock 里标记 3，那么支付成功后，一般就把 lock_stock 清零即可。
• 订单取消（超时未支付、用户主动取消等）：
  • 被“锁定”的库存要释放回可售库存：
  • 如果 stock 未扣减过，那么 lock_stock 减 3，stock 保持不变；
  • 如果 stock 在下单时就减掉了，那就要把 stock +3 回到 86，lock_stock 减到 0。

---

三、为什么会出现 lock_stock = -24？

在理想的锁库逻辑里，lock_stock 应该始终是一个大于等于 0 的数，因为它表示“被占用、锁住”的数量。出现 -24 一般可能是以下几种原因：

1. 数据紊乱或更新顺序问题
   • 某些逻辑写法：先扣减了 lock_stock，还没来得及把 stock 增回来，就被其他流程打断或出现异常，导致 lock_stock 累减到负数。
2. 库存字段含义混淆
   • 项目中把 stock 当作“理论库存”，而把 lock_stock 当作“实际可售库存 - 理论库存”的“差额”之类的含义，用法不一致。
   • 比如有人把 lock_stock 用来记“超卖”多少，正数或负数表示一种补偿量、差额量。
3. 历史数据遗留/手工修改
   • 运维或者运营人员直接在数据库手动改数据时输错了，造成负值。
   • 或者有批量清理脚本误把 lock_stock 扣成了负数。
4. 特殊业务场景：后置同步
   • 可能跟仓库系统做了对接，仓库反馈“少了 24 件”，或者“已经售出 24 件，但系统没及时更新 stock”，某些同步逻辑把这 24 件错误地记录在 lock_stock 里，从而出现负数。

在大部分电商主流做法中，很少会直接把 lock_stock 设为负数，因为从名称和常识上看，“锁定”本身就不应该是负的；但在有些系统里，他们的 stock、lock_stock 字段不完全按“可售库存 + 锁定库存”的思路来用，而是作为差异值或“校正值”。这就导致你看到的 lock_stock = -24。

---

四、举一个“带负数”情景的例子

假设在某些项目里，他们定义了如下计算公式：

可用库存 = stock + lock_stock

• 这里 stock 可能指“理论库存”或“原始库存”，
• 而 lock_stock 则是一个“校正量”（正数表示还可以用多少，负数表示超卖或需要补多少）。

那么，如果 stock=86，lock_stock=-24，意味着：

可用库存 = 86 + (-24) = 62

也就是系统当前真正可卖的只有 62 件。
把 -24 理解为：“这 24 个是已经超卖了，需要补回”。或是“已经被订单占用，超出了某个基准值”。

4.1 例子流程

1. 最开始 stock=86, lock_stock=0, 可卖 = 86。
2. 突然来了一波秒杀，下了 50 个订单（每个订单买 1 件），但是我们只及时更新了 “实际可卖” 的字段（可卖 = 36），并且把差额记录在 lock_stock。
3. 如果团队的做法是：lock_stock = “可用库存 - 原始库存” = 36 - 86 = -50（举例）。
   • 这样就出现了 lock_stock 是 -50 的情况。
4. 之后有 26 个订单又被取消了，系统把可卖库存恢复到 62，那么 lock_stock 也就变成 -24，表示还在被占用或者超卖的量是 24。

总之，这种“带负数”的用法是把 lock_stock 当作修正量而非简单的“锁住的数量”。

---

五、给你一个更直观的操作思路

如果你想要实现**正常的“锁库 + 释放 + 扣减”**逻辑，通常会这样做（不出现负数）：

1. 初始：

   • stock=86, lock_stock=0，可售=86

2. 用户下单（比如 5 件）：

   • 检查 stock 是否>= 5
   • 如果够用，则：
     • lock_stock += 5 ( lock_stock = 5 )
     • 同时 stock -= 5 ( stock = 81 )
   • （或者也有项目只改 lock_stock，不改 stock，看具体业务定义）

3. 订单支付成功：

   • 订单算是成交，这 5 件要真正扣减库存
   • 如果你在“下单时”就把 stock 改到 81，那么就只需要 lock_stock -= 5 = 0。
   • 如果你在“下单时”没改 stock，而是只给 lock_stock=5，那此刻就要真正 stock -= 5 = 81，并 lock_stock 回到 0。

4. 订单取消：

   • 把“下单时”占用的 5 件释放回 stock。
   • 如果“下单时”是 stock=86 → 81，那就此刻 stock=81+5=86，lock_stock=0。
   • 如果“下单时”只改 lock_stock=5, 没动 stock，那现在只需要 lock_stock=0 并保持 stock=86。

通过以上步骤，就可以很清晰地做到不出现锁定库存为负数。

---

六、总结

1. “常规”做法：

   • lock_stock 表示锁住的库存数，通常应 >= 0。
   • 订单下单时锁住库存、支付成功后实际扣减库存、订单取消时释放库存。

2. 你表中 lock_stock=-24 的可能原因：

   • 这在“常规锁库逻辑”中并不正常，常见于数据紊乱、特殊业务定义或人工干预等情况。
   • 某些团队把 lock_stock 当“差异量”或“超卖校正量”来使用，从而出现负数。

3. 如何修正或理解现状：

   • 先搞清楚项目里到底是如何定义 stock、lock_stock、以及“可用库存=?” 的算法。
   • 如果确实要保持常规逻辑，建议把 lock_stock 只用于“锁定的量”并确保其非负，把库存超卖、差异同步等逻辑放在别的字段或别的机制里处理。
   • 如果这是“遗留数据”，需要手工或批量脚本来修正负数，避免下次业务再出错。

总之，从你的示例可以推测，要么是“表中字段混用了其他含义”，要么是“系统曾经出现过异常或人工数据修改”。如果你们想把库存逻辑做得更“干净可控”，就最好遵循“锁定库存 = 正数”并配合清晰的加减流程，这样在查问题或扩展功能时更容易追踪。