2022年双11后，我帮一家女装电商做库存数据治理，打开SKU主表时发现：8.2万条SKU记录，实际在售商品不足2,100个；库存明细表里躺着3,000多条“状态启用但库存为0”的记录；而财务那边，每个月要花两个人天在“库存对不上账”上。这不是孤例，在我接触的十几家电商企业中，几乎没有一家能说清楚SKU库里有多少条有效记录。所谓“多SKU冗余库存”，表面看是仓库积压问题，根子上是数据库存的设计问题。
这篇文章围绕“数据库存SKU库存精简”这个主题，把我处理过的模型、踩过的坑和验证过的步骤完整写出来。
核心结论是：多SKU冗余库存的治理，应该从数据库的主数据模型开始，而不是从仓库盘点开始。
行业内对“冗余库存”的普遍理解是“卖不动的货太多”，于是习惯用“打折、促销、强配”去解决。但我在实际数据治理中发现，大量所谓“卖不动”的SKU，本身就是数据库里被错误创建、重复创建或已停用却未归档的“伪SKU”。这些伪SKU占用了编码资源、库存表空间、报表计算量，甚至拉低了动销率指标，让管理层误以为“品类太多、需要砍款”。
我统计过一家中型服饰企业的数据：业务意义上的冗余（即真正滞销、积压的货品）大约占全部SKU的15%～20%；而数据意义上的冗余（重复编码、停用未归档、属性残缺、映射错误）占比高达35%～40%。两者有交集，但交集不稳定。
SKU总记录数：82,000
状态为“启用”的SKU：31,000
近180天有动销的SKU：6,400
判定为业务冗余（存量积压）：1,150
判定为数据冗余（编码/映射/状态问题）：22,400
数据冗余是业务冗余的4～5倍，而且先于业务冗余产生。如果不先清理数据层，任何业务层的“清库存”行动都会把资源浪费在错误的SKU上。
“数据库存”强调的不是“库存放在哪些仓”，而是“库存数据在数据库里以什么结构存在”。同样一个SKU，在草稿表、临时表、正式表、历史表、报表里各有一份；同样一款商品，在自营ERP、电商平台、财务系统、WMS里分别被创建了不同的编码。这些数据无法归并，仓库里只有一个物理库存，数据库里却存在四个互相打架的数字。精简的第一步，就是把“无数个数字”归并成“一个可信的数字”。
我的处理顺序始终相同：模型规范化 → 冗余识别规则化 → 清理执行安全化 → 日常防控自动化。这四个步骤，后续章节逐一展开。
数据库存冗余不是一种抽象现象，它就发生在三张最常见的表里：SKU主表、库存事实表、编码映射表。
很多企业建SKU主表时，习惯把所有属性放进一张表：品牌、品类、颜色、尺码、年份、季节、供应商、采购员、自定义备注、定制属性……一张表动辄三四十个字段。
大宽表是数据冗余的天然温床。原因有两个：第一，每次新增一个属性就要改表结构，历史数据需要回填，回填不完整就产生空值；第二，运营为了在现有结构里表达“新款式”，会把不同含义塞进同一个字段，例如“颜色”里写“白色+加绒”，新SKU就这样被暴力创建。
# 精简前的SKU主表示例（仅展示核心字段）
sku_id VARCHAR(32)
sku_name VARCHAR(255)
brand VARCHAR(50)
category VARCHAR(50)
color VARCHAR(50)
size VARCHAR(20)
season VARCHAR(20)
supplier VARCHAR(50)
custom_note VARCHAR(255)
status TINYINT
我用三张表替代这张大宽表：SKU基础表、SKU属性表、属性字典表。基础表只存稳定且唯一的属性，属性表通过键值对关联扩展属性，属性字典表控制属性值的合法性。
— 精简后的SKU基础表
sku_id VARCHAR(32) PRIMARY KEY
spu_id VARCHAR(32)
sku_code VARCHAR(64)
sku_name VARCHAR(255)
status TINYINT
— 精简后的SKU属性表
sku_id VARCHAR(32)
attr_key VARCHAR(50)
attr_value VARCHAR(255)
— 属性字典表
attr_key VARCHAR(50)
attr_value VARCHAR(255)
is_active TINYINT
这样的拆分让SKU的创建从“大而全”变成了“小而准”，新增属性不需要改主表，属性值的唯一性也可以通过字典表控制。
库存事实表是冗余的另一高发区。多仓、多货位、多批次并行时，同一SKU在表里会有多条记录。这不是问题，问题是很多系统把“逻辑库存”和“物理库存”混在一张表里，没有做分层。
同一SKU既在“可用库存表”里有一行，又在“锁定库存表”里有一行，还在“在途库存表”里有一行，通过不同状态字段来标识。当同步链路出现延迟，这三行的数据不同步，账实不符就这么来的。
我把库存事实表拆成两个层级：实时库存流水表和每日库存快照表。流水表只记录库存变动事件（入库、出库、锁定、解锁、盘盈、盘亏），快照表每天凌晨汇总一次，用于报表查询。
— 库存流水表（实时写入）
id BIGINT PRIMARY KEY
sku_id VARCHAR(32)
warehouse_id VARCHAR(32)
change_type VARCHAR(20) — in/out/lock/unlock
qty_change INT
occurred_at DATETIME
— 库存快照表（每日汇总）
snapshot_date DATE
sku_id VARCHAR(32)
warehouse_id VARCHAR(32)
qty_on_hand INT
qty_locked INT
qty_available INT
PRIMARY KEY (snapshot_date, sku_id, warehouse_id)
拆分之后，实时查询走流水表，报表查询走快照表，既避免了一次查几十万行流水导致的性能问题，也减少了“同一SKU多状态记录互相矛盾”的失真风险。
多平台经营的商家一定会遇到：同一款商品，在淘宝、京东、抖音、微信商城各有一个平台SKU编码，系统里还维护着一个内部SKU编码，另有条形码。这些编码之间的映射关系如果缺少维护，就会产生两种典型孤儿数据：平台SKU已删除但映射表仍保留；内部SKU已停用但其平台编码被其他平台复用。
我在一个案例中发现，某品牌在映射表里存在近400条孤儿数据，其中60%对应的是三年前已经停售的商品。这些数据不会自己消失，它们只会持续参与后续的库存计算和报表汇总，造成越来越多的混乱。
解决方式：统一维护“平台SKU，内部SKU，条形码”的三级映射关系，并在每天同步结束后自动校验映射完整性。
我在很多企业做过同样的工作，发现大家一开始都会走弯路。这里把最常见的四个误区写出来，帮读者提前避坑。
库存冗余看似是采购决策问题，但如果你连SKU编码都无法对应到真实的商品，那么“少进哪个货”这个问题本身就无解。数据冗余不清除，你就看不到真实动销率，自然也说不清哪些SKU“该砍”。
判断：先治理数据，再调整采购，顺序不能反。
SKU的数量不是核心问题，粒度和编码质量才是。同一个商品，在数据库里只应有一条有效记录；这条记录可以关联多个属性、多个条码、多个仓库，但主键必须唯一。冗余不是说SKU太多，而是有很多SKU在重复记录同一件事。
在大多数情况下，清理冗余SKU不等于物理删除。SKU主表关联着历史订单、采购单、库存流水、财务报表、税务凭证。物理删除一条SKU，可能导致历史数据失去外键关联，审计时无法追溯，甚至影响财务报表的完整性。正确做法是“停用”和“归档”，而不是“DELETE”。
冗余SKU在日常运营中持续产生：运营新建了一个重复SKU、平台自动生成了一组编码、数据同步链路短暂故障导致重复记录。如果只做年度清理，一年间的数据污染会逐步扩大，清理成本也会越来越高。需要的是自动化防控机制，而不是一次性的突击行动。
这四步是这套方法论的核心，每个环节都可以直接拿去对照执行。
建模规范化的目标：让每个SKU在系统里只有一个唯一的、语义清晰的身份。
具体做法是建立“SPU→SKU→批次→序列号”的四层模型。SPU代表商品，SKU代表可售卖的最小库存单元，批次代表同一SKU在不同采购批次中的分组，序列号用于追踪单品（家电、3C、高价值商品需要）。
SPU: 商品，如“女款针织开衫-焦糖色”
SKU: SKU，如“NJ-2024-001-XL”（SPU的某个可售卖规格）
Batch: 批次，如“PO20241001”（对应某次采购入库的批次号）
SN: 序列号，如“SN20241215001X”（对应单个商品的唯一标识）
建模时用“SKU_ATTRIBUTE”表来存可扩展属性，避免“宽表陷阱”。这里的关键教训是：主数据模型不是一次建好的，要预留扩展能力，但扩展能力不应以字段堆砌为代价。
冗余识别必须依靠可量化的规则，而不是人脑记忆。我常用的判定规则包括以下三类。
（1）重复组合规则：找出属性完全相同的SKU。
-- 找出属性组合完全一致的重复SKU SELECT brand, category, color, size, season, COUNT(*) AS cnt FROM dim_sku WHERE status = 'active' GROUP BY brand, category, color, size, season HAVING COUNT(*) > 1 ORDER BY cnt DESC;
（2）零动销规则：找出长期无业务行为的SKU。
-- 找出过去180天无任何库存变动的SKU SELECT s.sku_id, s.sku_name FROM dim_sku s LEFT JOIN inv_movement m ON s.sku_id = m.sku_id AND m.occurred_at >= DATE_SUB(CURDATE(), INTERVAL 180 DAY) WHERE m.sku_id IS NULL AND s.status = 'active';
（3）映射关系规则：找出同一商品在不同平台存在多编码但未建立有效映射的SKU。
-- 找出平台SKU映射表中重复的内部SKU SELECT internal_sku_id, COUNT(*) AS platform_count FROM dim_sku_mapping GROUP BY internal_sku_id HAVING COUNT(*) > 1;
注意：判定规则只负责“疑似”，最终结论必须人工复核。比如零动销180天可能是季节性商品（羽绒服在夏季停售），不能只听规则算法。
确定冗余之后，处置方式有优先级：停用 > 合并 > 归档 > 物理删除，按这个顺序选择。
（1）停用：对不再销售的SKU，将status从active改为inactive，不删除任何历史数据。这是最安全的操作，也是默认选择。
（2）合并：对重复创建的SKU-A和SKU-B，将A合并到B，在A上打上“merged_to=B”的标记，并把A的库存历史记录挂到B名下（或保留在A名下但建立映射）。注意合并前必须确认在途订单、采购在途、库存余量都已处理。
（3）归档：对已经停用且历史记录完整保留的SKU，可在数据层将SKU主表记录移动到AREA归档表，或打上archived标记。归档后不再参与日常计算，但随时可回溯。
（4）物理删除：仅在确认没有任何下游引用记录（订单、流水、报表、凭证），且得到财务与审计确认后才能执行。多数企业不需要物理删除任何数据。
状态机设计示例如下：
status 状态流转
active（可售）→ inactive（停用）→ archived（归档）
active → merged_to（已合并）→ archived
每一步都记录：操作人、操作时间、操作原因、关联处置单号
冗余问题是防出来的。把冗余识别规则变成定时任务，在SKU创建的源头就拦截问题。
我采取的防控体系包括以下三层：
这样的三层控制可以把冗余的“生成速度”从每月几十个降到每月几个。实际效果差异明显：有防控的店铺，其冗余SKU数量在12个月内下降了90%以上；而无防控的对照组，冗余SKU数量平均反弹了约75%。
以一家中型电商企业为例：SKU总记录1万个，其中判定冗余860个，涉及库存金额约80万元（均摊到每个SKU约930元）。完成停用和归档后，有效SKU变为9,140个。
观察：精简带来的收益并非体现在“少卖了多少钱”，而是体现在以下多个维度。
（1）仓储空间释放。860个冗余SKU如果平均每个占用约0.01立方米，那释放的库容约为8.6立方米（约合两到三个标准货架）。折合仓储成本，每年大约节省1.2万～1.8万元。
（2）数据性能提升。库存流水表减少约30%的记录量，日终结账SQL的执行时间从平均42分钟降为18分钟，库存报表生成时间从25分钟降为9分钟。
（3）人力成本降低。财务月结单据的差异核对时间从每月2.5人天降为1人天；仓库盘点时遇到的“账上存在但库位为空”的异常项从每季度42项降到12项。
（4）财务风险降低。冗余SKU长期挂在账上，会推高存货账面价值；清理以后，存货减值测试的数据口径更清晰，审计时不需要反复解释“为什么库存金额里包含已经两年没动过的商品”。
综合来看，一个1万SKU规模的企业，完成一次有效精简，每年可节省的成本约为5万～8万元。这不是暴利，但考虑到实施周期通常只有两三周，投入产出比相当可观。
市面上常有人说“SKU精简让库存降低30%”，我不建议直接采信。原因很简单：各行业SKU的存量结构差异很大，30%在没有说明基数、行业和时间段的情况下无法验证。我的建议是：只对自有系统做基线测算，对比治理前后的同口径数据。
以下这五个操作，我见过不同团队踩坑，写出来供读者规避。
危险在于：历史订单外键会断裂。一旦删除SKU主表里的记录，过去3年的订单明细就找不到对应的商品信息。很多ERP系统在关联失效后，报表会自动跳出混乱数据，最终只能靠备份恢复，而备份恢复又会覆盖当天新增数据。这种事故我只经历一次就再也不敢碰DELETE了。
如果A合并到B，但A还有在途采购单或未发货订单，合并之后仓库收货可能匹配不到SKU，发货时会打错包裹。操作之前必须先确认：在途采购单已经改到目标SKU，未发货订单已经完成重新匹配。
我前面提到过，羽绒服在夏季零动销是正常现象。通过“零动销180天”规则识别出来的SKU，一定要再叠加“是否属于周期性/季节性品类”的判断，然后进行人工复核。否则，冬装还没到旺季就被你“精简”了，旺季来临时无货可卖。
仓库编码、货架编码在物理搬迁后如果没在数据库里同步更新，新旧编码会同时留在库存表里，产生新的“孤儿库存”。这类问题的隐蔽性更强，因为它不是单条记录错误，而是系统的参照关系整体失真。每次仓库调整后的48小时内，需要做一次完整的货位映射校验。
有些运营为了“图省事”，会直接用SQL改库存状态。排查两个多小时却无法判断是缺货还是数据错乱。更糟的是，操作不记录任何审计日志。我的原则是：所有数据库写操作（更新/删除），必须通过业务系统接口或至少留下审计日志，权限分级，责任到人。
不同业务模式的SKU冗余形成原因不同，取舍策略也不同。
在服装行业，决定SKU数量的主要是款式×颜色×尺码的笛卡尔积。我见过一家品牌把“款式+颜色”放在SKU里，但“尺码”没有独立建维度，导致每次改尺码表都要重做一批SKU。正确做法是：SKU粒度仍是风格×颜色×尺码，但尺码作为一个属性的维度表单独管理。精简时有同类虚拟尺码合并的空间，但不同的裁片/版型不能随意合并。
3C品类必须具备“批次+序列号”的跟踪能力。由于售后、保修、换货都会用到序列号，SKU不能轻易合并。这里“精简”的优先级应转向“编码标准化”和“序列号与SKU的正确关联”。冗余的根源往往是历史型号停产尾货未归档，以及客服误把“同一型号不同颜色”当成不同商品。
美妆日化的冗余更复杂，保质期在数据库里，而库存管理必须把“剩余天数”纳入判定。策略是：离有效期的天数少于等于某个阈值（如90天）就对SKU进行特殊标记；一旦过期，立即归档并启动报废流程。此类SKU的合并空间极小。
做批发经销企业的特征是“一个上游SKU对应多个下游客户SKU”。这家企业的问题往往是“同一上游货品被渠道商创建了一套自己的编码”。精简时，优先统一上游编码体系，将下游编码作为关联属性，而不是每新增一个渠道就重做一套SKU。
行业差异的总结是：合并原则不变，但“可合并SKU的判定”需要结合行业属性。
运营必须在新建SKU时完成“查重校验”。这不仅是一个意识，更应在系统里做成硬性流程：新建SKU时如果命中名称相似、属性相同或平台映射冲突，系统应提示运营“选择关联已有SKU”或者“强制继续创建”。强制继续创建必须填写理由，并指定审批人。这一步解决了85%的新增冗余问题。
财务人员看到库存数据混乱时，通常会打回让仓库重新盘点，这个做法本身效率低。我的建议是：库存治理期间，财务要求输出“账龄结构表”和“效期结构表”，暴露可疑存货分布。当数据治理把冗余层清理后，财务的存货减值测试、审计解释负担都会明显下降。
仓库每次盘点的差异数据，是最真实的主数据修正来源。当系统某SKU显示“零库存”但在仓库里找到货，或者系统里显示“有库存”但库位空置，仓库需在24小时内提交差异单，并触发主数据修正流程。这会让数据库的库存字段始终逼近物理现实。
数据治理不是“启动一次就结束”的项目。我建议：每月固定一次30分钟的“冗余数据审查会”，由运营、技术、财务各指定一名代表，用前文提到的《冗余SKU治理月报》作为输入，决策下月需要处置的SKU清单。这类例会的价值在坚持3～6个月后才能显现，但它能把冗余SKU的数量从“月月新增几十个”逐步降至“偶尔新增一两个”。
写了一整篇，最后给出四个可直接行动的建议。
第一，动手前先建立数据基线。用你系统的真实数据回答：共多少SKU、启用多少、动销多少、疑似冗余多少、冗余涉及库存金额多少。没有基线，就无法评价任何优化的效果。
第二，先治理“伪冗余”，再谈“真冗余”。先把重复编码、停用未归档、映射错误、仓库数据未同步这些问题解决掉，再讨论“哪些正常SKU该被淘汰”。顺着这个顺序做，你会发现所谓积压库存比想象中少得多。
第三，所有清理操作分阶段执行，并统计风险指标。推荐以“周”为节奏：第一周只做识别与统计，输出疑似清单；第二周完成人工复核与方案确认；第三周开始对安全SKU执行“停用”；第四周统计异常订单率和账实相符率变化。
第四，从专项清理过渡到制度化防控。把查重校验、周期扫描、月度报告、月度例会固化到日常运营流程中，让冗余数据“产生即被发现、发现即被处置”。
数据库存SKU精简的目的不是把表删干净，而是让每一次库存决策都建立在可信的数据上。思路理顺了，表格结构优化了，规则建起来了，冗余自然会慢慢消失。如果你正在面对多SKU库存困扰，建议从本文第四步开始：先跑一遍冗余识别SQL，看清你的数据库里到底有多少条“伪SKU”，再决定下一步动作。
我在电商公司负责供应链数据，系统里现在有两万多个重复SKU，老板催着清理。但我最怕的是合并之后在途订单匹配不上、历史报表对不齐。之前的同事就是因为强行清理吃过亏，被打回原形。有没有一套经过验证的安全流程？先停用还是先合并？物理删除到底能不能碰？
先说结论：清理冗余SKU必须走‘停用→合并→归档’三步状态流转。任何直接物理删除的行为都是给自己埋雷，这是我在多个数据治理项目里验证过的铁律。我曾在2021年参与一家服饰电商的库存数据治理项目，系统里有12万个SKU编码，但实际在售的只有2.3万个。
当时技术负责人提出‘把重复记录全删了’，我拦了下来。一旦物理删除，历史订单的外键关联直接断裂，下单记录里的SKU变成空引用，财务对账时找不到商品，审计追溯路径断掉，这是任何系统都无法修复的灾难。正确做法是设计一个字段状态机，用状态位代替物理删除。
第一步，给SKU主表增加status字段，取值范围active（在用）、inactive（停用）、archived（归档）。清理时先将冗余SKU从active改为inactive，此时该SKU不再参与任何新订单创建、补货计划和库存统计。
第二步，建立SKU合并映射表，记录旧SKU编码到保留SKU编码的映射关系。这张表是业务层、报表层、数据仓库层共同查询的中间桥梁。第三步，将inactive状态转为archived，正式退出业务视图。合并映射表必须记录合并时间、合并操作人、合并原因三项审计字段。
这个设计在做季度存货减值测试时极为有用，财务人员可以直接从映射表还原任意时间点的库存口径，不需要反向推导。在途订单的处理有明确检查清单：第一，确认所有包含该SKU的待发货订单、采购在途、调拨在途已消化完毕；第二，确认该SKU最近30天无动销记录；第三，确认该SKU未参与预售或定期购活动。
任何一项未通过，就不能进入停用队列。关于历史报表，我的经验是：千万不要反过来修改历史订单里的SKU编码。正确做法是在订单明细里保留原SKU编码，报表查询时通过映射表关联到当前有效SKU。这样历史快照不被破坏，新口径也能统一。
老板丢给我一句话：‘把冗余SKU清一清。’可‘冗余’这个词太模糊了。我总不能把库里所有180天没卖的都标记为冗余吧？季节性商品怎么办？预售品怎么办？我需要一套拿得出手的判断规则，最好是能写成SQL查询的硬条件，而不是靠经验拍脑袋。
把‘冗余’拆成三类可量化的规则：时间冗余、属性冗余、空间冗余。三类规则独立触发即可认定‘疑似冗余’，全部进入人工复核环节。第一类，时间冗余。核心规则是‘零动销周期’。我通常用180天作为标准线：SKU最近180天无新增订单、无库存调整、无采购入库，即可标记为时间冗余。注意排除季节性商品和预售品。
所以我的SQL里会额外加一层品类过滤，把seasonal_type='on'的品类放到观望列表，不做自动标记。第二类，属性冗余。当两个SKU的产品ID相同、品牌相同、品类相同，只有颜色或尺码标签不同，就触发相似度打分。我建立的规则是相似度≥90%且两个SKU销量占比极端失衡时，判定为疑似属性冗余。
举例：一件白T恤主SKU月销800件，另一个同款但颜色描述多加了一个空格的SKU月销0件，大概率是同一件商品被重复建档了。第三类，空间冗余。这类冗余不发生在SKU主表，而发生在库存事实表。判断规则是：同一SKU在同一仓库的多个货位上存在碎片化库存记录。
我通过SQL聚合查询货位碎片化系数，系数超过50%的SKU需要被标记。也就是说，这个SKU在超过一半的货位上都有库存记录，平均每处不到5件。这会直接拉低拣货效率。
每个季度由数据分析团队输出一份《冗余SKU诊断报告》，报告中包含四个核心指标：疑似冗余SKU数、疑似冗余SKU覆盖库存金额、建议停用比例、需人工复核数。有了这份报告，决策者十分钟内就能判断该不该启动清理。识别规则中相似度判断是重点。最浅层的做法是直接比较SKU编码，这不够。
我增加两个维度：名称文本相似度和属性字段重合度。文本相似度用编辑距离或Jaccard相似度实现；属性字段重合度直接比对规格、颜色、尺寸三个字段是否相同。双层匹配把重复建档识别率从60%提升到90%以上。
我是一名后端开发，需要的是真正能跑在Navicat里的SQL语句。搜遍全网看到的都是‘做好库存管理’‘合理规划SKU’这种正确的废话。谁能告诉我第一步跑什么查询把重复SKU找出来，第二步跑什么语句把零动销的捞出来？有没有人在生产库上实际验证过？
我先把重复建档的SKU一次性捞出来，这是项目里最常用的诊断脚本： `
SELECT s.sku_code, s.sku_name, COUNT(*) AS record_count FROM sku_main s WHERE s.status = 'active' GROUP BY s.sku_code, s.sku_name HAVING COUNT(*) > 1 ORDER BY record_count DESC;这条语句在MySQL或PostgreSQL上可以直接运行。数据量超过百万级时，sku_code上最好有索引，否则会触发全表扫描，影响线上性能。
接下来是零动销识别，把180天没有销售记录的SKU捞出来： `
SELECT s.sku_code, s.sku_name, MAX(o.order_date) AS last_sale_date FROM sku_main s LEFT JOIN order_detail o ON s.sku_code = o.sku_code WHERE s.status = 'active' GROUP BY s.sku_code, s.sku_name HAVING MAX(o.order_date) IS NULL OR MAX(o.order_date)使用LEFT JOIN是关键，它能保证完全没有销售记录的SKU也被查出来。我之前用INNER JOIN写过，结果零销售的SKU全被过滤掉，诊断报告形同虚设。
更进阶的查询是找出同款商品下属性高度相似的SKU组合： `
SELECT a.sku_code AS sku_a, b.sku_code AS sku_b, a.sku_name, b.sku_name, a.color, b.color FROM sku_main a JOIN sku_main b ON a.product_id = b.product_id AND a.sku_code注意我用a.sku_code < b.sku_code而不是<>。这样每一对组合只出现一次，不会产生两条对称的重复记录。执行任何查询前先在测试库验证语法兼容。要更新生产数据时，先在事务里UPDATE并回滚，确认影响行数在预期范围内再提交。
我经历过一次直接在线上库执行DELETE，原本预期影响2万行，结果影响200万行，回滚窗口根本来不及，最后从备份花了三小时恢复。工具层面，选择支持连接管理、语法高亮和结果导出的数据库客户端就够用，不追求大系统。执行清洗任务前，把诊断SQL固化到脚本仓库。这样做有两个好处：一是团队能审查查询逻辑；
二是每条诊断规则有版本历史，后续优化可追溯。
上季度我们花了整整三周把4万多个冗余SKU清完了，库存表干净得像是新系统。可这个季度一看，又冒出来几千个重复建档的SKU，业务部门总喜欢‘先建一个再说’。这账目很快就乱了。我想请教：你们是通过什么样的机制挡住新冗余SKU产生的？
清理后反弹是必然的，真正的问题不是业务部门乱建码，而是你缺少一个‘创建就拦截’的机制。识别是治疗，防控才是免疫。第一层防线是建码审批流。所有新SKU创建必须经过查重校验节点。系统在业务人员提交申请时自动触发三重查重：第一重检查SKU编码是否已存在；
第二重检查产品ID+颜色+尺码+规格的属性组是否已存在；第三重检查名称相似度，用编辑距离算法扫描已有SKU名称中相似度超过85%的记录。三重结果实时展示在创建页面上，命中任何一项就阻断保存。第二层防线是定时扫描任务。
我之前的团队每周一早上8点定时跑冗余诊断脚本，生成《周度疑似冗余SKU清单》推到工作群。清单包含五个字段：疑似冗余SKU数、新增疑似冗余数、涉及库存金额、建议处置方式、风险等级。周报是业务部门的自我约束，不需要指责谁，数据摆在那里，大家会自觉比对。第三层防线是季度复盘会。
每季度召集运营、采购、仓库、财务四方开一次数据治理复盘会。内容很简单：把过去90天新增SKU和停用SKU两条曲线放一张图里对比。曲线越来越陡说明防控失效；曲线平缓说明前两个防线在正常工作。第四层建议是给SKU主数据设‘Owner’责任制。
每个品类指定一个业务Owner，对新SKU的唯一性和质量负最终责任。可以把SKU创建申请、查重结果、审批记录做成一个可追踪的任务流，用某项目管理工具承载。Owner在季度考核中加入：名下品类新增冗余率不超过3%。目标和考核对齐后，业务部门建码速度自然收敛。最后守住红线：物理删除永远禁用。
所有冗余SKU只能走状态机流转。每条SKU记录都是历史的一部分，订单可能一年后被消费者申请售后，税局可能三年后调取存货明细。缺少原始SKU信息就只能靠猜测对账，轻则补说明，重则担审计风险。
读者评论
作为数据治理工程师，这篇文章说到点上了。大宽表确实是冗余温床，我们公司SKU表有40多个字段，每次加属性都要改表结构，空值一堆。文中拆成基础表+属性表+字典表的做法很实用，尤其属性字典控制合法值，能从源头减少乱填。第二步的流水表+快照表拆分也很推荐。
做电商运营五年，一直以为库存冗余就是卖不动，天天想着促销清货。看完才明白，很多所谓滞销SKU根本是重复编码和停用未归档造成的假数据。我们系统里肯定也有几千条这种伪SKU，难怪动销率那么低。下一步得先求技术把数据清一遍，再谈采购决策。
财务视角来看，每月库存对账最头疼。正文说的'一个物理库存，数据库里却有四个数字'太真实了。平台编码、内部编码、条码映射混乱，导致平台库存和ERP库存永远对不上。文中库存流水表和快照表的拆分，以及每日校验映射关系，如果能落地，能省不少人天。
比较认同误区四的观点。我们之前每年让IT手动清一次，效果持续不了俩月，运营随手就新建重复SKU。现在必须把自动化防控做进日常流程，比如创建SKU时实时查重、停用自动归档、同步后校验映射。文章的四步方案可以当作实施参考，但落地还要结合自己系统。
作为一个小网店老板，虽然没有几万SKU，但同样会重复建款。比如同款不同批次，我老喜欢新建一个商品，时间一长就分不清哪个在卖。看完后我打算先整理编码规则，不用的就停用，别再删了，因为历史订单还要追溯。文章语言不绕弯，实操性强。