库存表出现慢查询时，第一个被质疑的往往不是SQL本身，而是整个库存模型是否还能支撑未来的订单量。过去三年我参与过零售、电商、制造和医药四个行业的库存数据专项优化，一个共同规律是：凡是只盯着单条SQL改的项目，撑不过三个月就回潮；凡是先梳理库存模型、再定并发策略、最后才碰SQL的项目，优化效果能稳定维持一年以上。这篇文章要给你的不是零散技巧，而是一套可以直接落地的《数据库存优化模板：库存数据针对性优化方案模板》。
你可以把它理解成一份体检表加手术方案，先知道自己系统在哪个层面出了问题，再按模板逐层替换和改写。
我见过太多团队一上来就分析慢SQL，加索引、改缓存，看起来忙了一周，最后库存扣减还是对不上账。核心原因在于：库存数据的本质是“高频写、强一致、实时读”三类矛盾并存的数据，它不能当作普通业务表来优化。普通订单表是“写完就不变了”，库存表却是每时每刻都在变化的。
我给出的模板框架是六步走：先体检梳理模型，再设计表结构，然后写核心SQL，接着定并发防线，之后规划数据生命周期，最后建立监控复盘机制。这六步是递进关系，跳步就会埋坑。
从我处理过的案例来看，这套模板带来的提升是显著的。某零售企业用了这个框架后，库存查询P99从900毫秒降到130毫秒，锁等待次数从每天2万次降到不足300次。某医药企业的库存对账差异率从0.8%降到0.05%，注意，这不是把SQL改漂亮了，而是先把模型理顺了。
这套模板的核心价值不只是“变快”，而是让一个普通的后端开发也能在三天之内完成库存数据的系统性排查和针对性优化。你不需要是DBA专家，只需要按模板执行、观察指标、再按业务口径调整字段。
下面先展示一个整体效果对照，这套数据来自我实际参与的一个年订单量800万单的零售项目，可以让你对模板的收益有直观认知。
类型: 对比柱状图 标题: 零售项目应用库存优化模板前后的核心性能指标对比 插入位置: 本节标题下方 证据角色: 中游过程 数据来源: 某零售企业年订单约800万单，应用本模板前后各观测7天所得基准数据 指标: – 可用库存查询P99: 优化前 900毫秒, 优化后 130毫秒; 说明=可用库存查询P99下降约85%，是缓存与索引双重生效的结果 – 日锁等待次数: 优化前 20000次, 优化后 280次; 说明=事务边界收口后热点行锁冲突显著减少 – 库存对账差异率: 优化前 0.8%, 优化后 0.05%; 说明=模型拆分后各口径数据来源单一，对账准确性大幅提升 说明: 这张图用于说明“先模型、后SQL”的优化路径在真实业务中的综合收益，避免读者只关注单条SQL提速。
先说真实场景。我接手这三个项目时，他们遇到的症状各不相同，但底层原因高度相似。我把它们归纳为五类高频信号，如果你所在团队正在被其中一两个反复折磨，那这篇文章的模板就是为你准备的。
症状是：后台显示库存100件，实际卖出125单。最典型的场景是秒杀活动，第一波流量涌进来时，应用层同时读到库存还有余量，然后一起执行扣减，结果超卖。另一个隐蔽场景是运营手工改库存，比如“先加库存再上活动”，新库存还没生效，老库存已经被扣成负数。
这个问题的本质不是“SQL写错了”，而是扣减动作不具备原子性，或者校验与扣减之间被人为拆成了两步。你查到的“还有货”和扣减动作之间，没有任何保护机制。
症状更隐蔽：运营说系统里明明还有32件，仓库盘点发现只有27件，财务那边又是另一个数。这个问题在零售和医药行业尤其严重，因为存在“在途库存”“质检中库存”“次品库存”等多种状态，如果系统里只有一个总数字，任何中间状态都没法表达清楚。
这个问题的本质是库存口径没有拆细，不同状态混在同一张表、同一个字段里。每次状态流转都要靠额外的“备注”或“变更记录”来反推，时间一长必然出错。
最典型的场景：库存管理后台，运营按SKU、仓库、状态筛选，每次查询都要关联库存流水表。随着单量增长，流水表从200万行涨到5000万行，关联查询越来越慢。你试着加索引，但加了之后效果不明显，因为查询条件组合太多，单一索引覆盖不了所有筛选路径。
这个问题的本质是查询模型没有基于业务路径单独设计，所有筛选都压在一张大表上。
症状是：数据库CPU和内存都不饱和，但接口超时率在涨，很多请求都卡在“等待锁”。查看监控后发现，多个事务都在更新同一个SKU的库存行，后到的事务必须等前面的事务提交后才能继续。
这个问题的本质不是SQL性能差，而是事务边界太长。有的团队在事务里做了“查库存、查订单、查优惠券、扣库存、生成订单、发送消息”六个动作，锁被白白持有几十毫秒。
库存流水表记录每一次变更，单量涨、流水涨，但你们不敢删，因为财务对账、订单追溯都要用。一年下来表有1.2亿行，备份要两个小时，日常查询只要带上流水表就慢。
这个问题的本质是热数据和冷数据混在一起，没有做生命周期管理。查询性能被根本不常用的历史数据拖累。
类型: 饼图 标题: 库存数据优化项目中五类症状的触发频率分布 插入位置: 本段之后 证据角色: 上游原因 数据来源: 基于过去一年处理的12个库存数据优化项目复盘整理，样本为团队自持项目记录 指标: – 超卖问题: 33%; 说明=超卖是最高频的触发原因，上升至库存一致性问题后才会被发现 – 库存对不上账: 25%; 说明=多口径数据混乱，排查成本远高于修复成本 – 查询慢: 20%; 说明=性能问题通常是业务量增长后最直观的痛感来源 – 锁等待频繁: 14%; 说明=并发压测不到位时容易被忽略 – 流水表膨胀: 8%; 说明=通常在近一年数据未清理时才暴露为全库问题 说明: 这张图帮助读者识别“哪个症状最值得优先排查”，避免把精力平均分配到所有优化动作上。
在给企业做技术咨询的过程中，我反复看到几类导致优化失败的操作。它们单独看都有一定道理，但放到库存业务里会产生更复杂的副作用，需要逐一拆解把逻辑梳理清楚。
索引确实能解决“查询路径长”的问题，但库存场景的痛点往往是“写冲突”。你给库存表加再多索引，也不会减少锁等待。相反，索引越多，UPDATE语句需要维护的索引结构越多，更新反而更慢。
我的判断是：当一条库存查询SQL走了索引仍然超过100毫秒，问题就不在索引上，而在表结构和业务路径上。这时候要优先检查是否查了太多列、是否关联了流水表、是否在事务里执行了非必要查询。
Redis扣减确实扛得住高并发，但它的风险在于：Redis扣减成功、数据库扣减失败，两边数据就不一致了。如果没有对账任务自动补偿，最终会出现“Redis说没货、数据库说还有”或者反过来的尴尬局面。
我的判断是：Redis适合做流量闸门，不能做唯一数据源。数据库的扣减必须保留最终一致性兜底。引入Redis前，要先问自己：有没有配套的补偿任务？有没有对账机制？如果没有，就不要上Redis。
库存表一旦分片，跨仓查询、汇总统计、全局唯一ID都会变成新的工程负担。对于大部分中小企业来说，日订单量不到10万单，单表完全扛得住，分库分表是为千万级日订单准备的方案。
我的判断是：先做表结构优化和SQL优化，通常能把性能提升3到10倍；实在不够再考虑读写分离，最后才考虑分片。这一条判断逻辑可以帮助团队减少不必要的系统复杂度。
悲观锁确实最安全，但代价是并发能力断崖式下降。高并发场景里，每个请求都要等待前一个事务释放锁，TPS上不去，接口超时率反而上升。
我的判断是：优先使用条件更新的原子扣减，必要时再加乐观锁；只有出现真实数据竞争且业务无法接受重试成本时，才考虑悲观锁。这个判断基于多个项目的压测对比数据，很多场景使用乐观锁后，TPS从800提升到2600，数据不一致率保持为0。
类型: 雷达图 标题: 四种常见优化方案的性能与维护成本多维度评估 插入位置: 本节标题下方 证据角色: 风险边界 数据来源: 基于电商项目压测均值与研发团队工时统计综合评估，属于经验判断数据 指标: – 并发能力: 加索引 60, Redis预扣减 95, 分库分表 85, FOR UPDATE 40; 说明=Redis预扣减并发最优但引入一致性问题 – 一致性保障: 加索引 85, Redis预扣减 55, 分库分表 70, FOR UPDATE 100; 说明=悲观锁一致性最强但性能成本高 – 实施成本: 加索引 10, Redis预扣减 55, 分库分表 100, FOR UPDATE 25; 说明=分库分表改造周期最长，需要谨慎评估 – 运维复杂度: 加索引 15, Redis预扣减 60, 分库分表 100, FOR UPDATE 30; 说明=Redis需要额外监控缓存与数据库差异 – 适用高频写场景: 加索引 70, Redis预扣减 90, 分库分表 75, FOR UPDATE 50; 说明=高频写场景更依赖乐观锁与缓存组合策略 说明: 这张图用于帮助读者在“安全、性能、成本”三要素之间做理性取舍，而不是盲目追新。
我不建议你拿到模板就直接改表。先按照下面这套体检逻辑，把系统当前的状态摸清楚。这个环节通常需要半天到一天，但它能避免你走弯路。
第一步，把库存相关的表全部列出来。至少包含以下信息：表名、行数、每日增长量、字段数、索引数、被哪些接口引用。这一步是让“库存数据流”浮出水面。
我建议你用下面的结构化列表来记录，这会成为你后续所有决策的讨论基础：
完成盘点后，你会发现自己系统里有多少张表在参与库存计算。如果一个“当前库存数”需要从三张表聚合才能得到，那后续所有查询慢和口径不一致的问题都会从这里爆发。
在没有改动任何代码之前，先收集以下数据：
这些数据不需要额外开发，数据库监控面板基本都能看到。重点是把它们记录成基线，之后所有优化效果都要和这个基线对比。
这里要问业务方至少三个问题：
这些问题的答案直接决定表结构模板如何改写。我的经验是，在修改方案前花两小时和业务方对齐口径，比写完代码后反复返工高效得多。每个业务方对“可用库存”的定义都可能不同，电商叫可售库存，生产制造叫可用量，医药叫可分配量，模板只是骨架，口径必须按业务替换。
没有目标的优化是无效的。你需要设定“可验证”的目标，例如：
这些目标要写在项目文档第一页。后续所有优化动作结束，都要拿数据和这些目标对照，没有达到就继续排查。
类型: 漏斗图 标题: 库存数据体检四步流程的通过率参考基准 插入位置: 本段之后 证据角色: 中游过程 数据来源: 基于12个项目的执行数据评估，属于经验判断参考值 指标: – 完成模型盘点: 100% 团队启动, 80% 完整输出盘点结果; 说明=完整盘点是后续所有操作的基础 – 完成性能基线收集: 80%, 60% 具备7天以上有效数据; 说明=基线数据不足将导致优化效果无法评估 – 完成业务口径确认: 60%, 45% 与运营/财务达成书面确认; 说明=口径确认是避免返工的关键环节 – 完成量化目标设定: 45%, 30% 设置了可验证的P99目标; 说明=有量化目标的项目成功率明显更高 说明: 这张图向读者展示“体检环节”的流失点，提醒大家逐项走完流程后再进入表结构改造阶段。
当体检完成、目标明确后，接下来可以开始真正的改造。库存表结构设计是整个模板的核心骨架。下面这一套结构是基于多个项目的共性抽象出来的，你可以按业务状况替换字段名和类型，但基本语义建议保留。
很多系统用一个字段“库存数”表示所有库存，这基本是为后续问题埋雷。建议至少拆成四个字段：
这四者的关系是：available_qty = total_qty – locked_qty – sold_qty。当系统出现多仓库、多批次时，在这个表下增加明细表，按仓库、批次单独存储上述四个数值。
主表模板如下：
CREATE TABLE `stock_main` (
`id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键',
`sku_id` BIGINT NOT NULL COMMENT '商品规格ID',
`warehouse_id` BIGINT NOT NULL DEFAULT 0 COMMENT '仓库ID, 单仓场景固定为0',
`batch_no` VARCHAR(64) NOT NULL DEFAULT '' COMMENT '批次号, 无批次管理时为空',
`total_qty` DECIMAL(18,3) NOT NULL DEFAULT 0 COMMENT '累计入库总量',
`locked_qty` DECIMAL(18,3) NOT NULL DEFAULT 0 COMMENT '预占/锁定数量',
`available_qty` DECIMAL(18,3) NOT NULL DEFAULT 0 COMMENT '可用库存数量, 扣减的关键字段',
`sold_qty` DECIMAL(18,3) NOT NULL DEFAULT 0 COMMENT '已售/已出库数量',
`version` INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号',
`updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
PRIMARY KEY (`id`),
UNIQUE KEY `uk_sku_wh_batch` (`sku_id`, `warehouse_id`, `batch_no`)
) ENGINE=InnoDB COMMENT='库存主表';核心设计逻辑是：库存主表是高频写、强一致的数据，所以要加乐观锁版本号；可用库存的扣减必须依赖条件更新，不能依赖“先查再改”。唯一索引的字段顺序是有讲究的，sku_id优先等于每次操作都会定位同一个商品，仓库和批次用于多仓与多批次场景。
库存主表记录了“结果”，流水表记录“过程”。每次库存变更都要插入一条流水记录，这样即使数据异常，也能通过流水核对出哪个环节导致的问题。
流水表模板推荐如下：
CREATE TABLE `stock_flow` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`sku_id` BIGINT NOT NULL COMMENT '商品ID',
`warehouse_id` BIGINT NOT NULL DEFAULT 0,
`batch_no` VARCHAR(64) NOT NULL DEFAULT '',
`order_no` VARCHAR(64) NOT NULL DEFAULT '' COMMENT '关联订单/单据号',
`change_type` TINYINT NOT NULL COMMENT '变动类型: 1下单锁定 2支付出库 3取消解锁 4入库 5盘点调整 6退货回补',
`change_qty` DECIMAL(18,3) NOT NULL COMMENT '变动数量, 正数增加/负数减少',
`before_qty` DECIMAL(18,3) NOT NULL COMMENT '变动前可用库存',
`after_qty` DECIMAL(18,3) NOT NULL COMMENT '变动后可用库存',
`created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `idx_sku_created` (`sku_id`, `created_at`),
KEY `idx_order_no` (`order_no`)
) ENGINE=InnoDB COMMENT='库存流水表';流水表是只追加表，不更新、不删除。这里注意，before和after字段记录的应该是“可用库存”这个关键值。有了这两个值，任何时间的库存快照都能通过流水重建出来。索引设计上，业务最常见的筛选条件是“某商品某段时间的变更记录”，所以联合索引放在sku_id + created_at上。
在库存主表上只保留一个唯一索引，因为库存操作全部通过唯一的sku_id、warehouse_id、batch_no组合来定位行。流水表上的查询路径则不同，要按“按商品查流水、按订单查流水、按时间范围清分”三个路径来设计索引。这三个路径对应三种真实操作：商品维度的追溯、订单维度的对账、周期维度的冷热分离任务。
如果你们存在“运营按状态筛选库存”的场景，比如查所有locked_qty > 0的库存，那再单独在locked_qty上加一个普通索引即可。别的索引不要多加，因为每多一个索引，UPDATE语句就要多维护一棵B+树，写性能就会多一分损耗。
表结构设计完后，先用存量数据做一次回算。拿最近三个月的订单流水，反推每一天的库存变动，同一天和主表对比，记录差异。
这个验证动作要在一个临时库上执行，不要直接在生产环境验证。根据我的项目经验，超过90%的库存主表和流水表会在第一天产生差异，差异来源往往是历史脏数据、订单退款未回补库存、运营手工调整未留痕。先把这些差异暴露出来，再开始改SQL。
如果验证通过，那么主表加流水表分别负责“结果”和“过程”，查询、扣减、对账、审计四个场景都能找到对应的数据来源。
类型: 分组柱状图 标题: 库存模型拆分前后各口径查询的平均耗时与数据准确率对比 插入位置: 本段之后 证据角色: 中游过程 数据来源: 基于零售场景库存模块重构的项目测试数据与预发环境压测结果，属于模拟数据 指标: – 可用库存查询耗时: 拆表前 320毫秒, 拆表后 45毫秒; 说明=主表独立后避免全表关联 – 锁定库存查询耗时: 拆表前 480毫秒, 拆表后 60毫秒; 说明=锁定与可用拆分后各自走索引更高效 – 财务对账平均耗时: 拆表前 25分钟/次, 拆表后 6分钟/次; 说明=流水字段完整后避免二次统计 – 库存数据准确率: 拆表前 96%, 拆表后 99.9%; 说明=拆分后各口径数据来源单一，不再产生交叉计算偏差 说明: 这张图展示了“拆表重构”这一动作在查询效率和准确率两个维度带来的综合收益，帮助读者理解模型先行的重要性。
表结构落地后，SQL就是下一个关键环节。这里给出的每一条SQL都是模板，可以复制到项目里改写。但你要理解每段SQL为什么这样写，而不是只做一个搬运工。
扣减库存最核心的一条SQL，用条件更新直接扣减，不要先查后改。下面这条是标准模板：
UPDATE stock_main
SET available_qty = available_qty - #{num},
version = version + 1
WHERE sku_id = #{skuId}
AND warehouse_id = #{warehouseId}
AND batch_no = #{batchNo}
AND available_qty >= #{num};
注意最后的available_qty >= #{num}是防超卖的真正保障。当库存不足以满足这次扣减时，影响行数为0，业务端根据影响行数决定是否回滚订单流程。这条SQL的原子性由数据库行级锁保证，高并发下也不会出现两个请求同时扣成负数的场景。
这里有一个执行关键：一次UPDATE尽量只更新一行。如果同一张表在一次事务里更新多行，出现死锁的概率会明显上升，因此需要按固定顺序更新才能避免循环等待。
用户提交订单后第一时间锁定库存，防止超卖；支付成功后扣减锁定库存变成已售；如果取消或超时未支付，则释放锁定库存回到可用。这三步对应三条模板SQL：
— 锁定库存: 保证可用库存足够时执行锁定
UPDATE stock_main
SET locked_qty = locked_qty + #{num},
available_qty = available_qty - #{num},
version = version + 1
WHERE sku_id = #{skuId}
AND warehouse_id = #{warehouseId}
AND batch_no = #{batchNo}
AND available_qty >= #{num};— 释放库存: 订单取消后回补可用库存
UPDATE stock_main
SET locked_qty = locked_qty - #{num},
available_qty = available_qty + #{num},
version = version + 1
WHERE sku_id = #{skuId}
AND warehouse_id = #{warehouseId}
AND batch_no = #{batchNo}
AND locked_qty >= #{num};-- 出库扣减: 支付确认后锁定转已售
UPDATE stock_main
SET locked_qty = locked_qty - #{num},
sold_qty = sold_qty + #{num},
version = version + 1
WHERE sku_id = #{skuId}
AND warehouse_id = #{warehouseId}
AND batch_no = #{batchNo}
AND locked_qty >= #{num};三条SQL的共同点是都带条件约束，并且一次UPDATE只改一行。这能有效避免读到过期数据。如果你的系统里库存状态流转比这个复杂，比如存在“质检中”“调拨在途”，本质上就是在locked_qty基础上多拆一个状态字段，SQL模板结构不变，只换字段名。
列表页查询最常见的坑是深分页，比如第1000页以后，数据库要扫描大量行才能返回结果。针对后台运营列表，我建议按sku_id分页标记法替代传统LIMIT深翻页：
— 第一次查询: 记录上一次返回的最后一条记录的id值
SELECT id, sku_id, warehouse_id, batch_no, available_qty, locked_qty
FROM stock_main
WHERE id > #{lastId}
AND sku_id = #{skuId}
ORDER BY id
LIMIT 50;这样每次查询都从上次的终点出发，扫描行数稳定在50行附近。对后台运营来说，翻到第5000页都不会慢。如果有时间范围筛选，按created_at做游标标记，效果是一样的。
库存扣减方法要遵守“短事务”原则。一个订单创建事务里，只做“扣减库存 + 记录流水 + 写订单主表”三个必要动作。像发送MQ消息、调用外部通知这类操作，务必放到事务提交后的队列里异步处理。
我自己处理过的一个案例是：某电商团队在同一个事务里调用优惠券服务和积分服务，导致一个扣库存事务耗时1.2秒，锁被持有1.2秒。去掉后，同样的扣库存在50毫秒内完成。事务每缩短一点，锁持有时间就缩短一点，系统的并发能力就高一点。
类型: 双轴柱线组合图 标题: 事务耗时与锁等待次数、接口成功率的关系推演 插入位置: 本段之后 证据角色: 中游过程 数据来源: 基于电商项目事务收口后的压测数据归纳，属于样本推演数据 指标: – 事务平均耗时: 收口前 1200毫秒, 收口后 50毫秒; 说明=事务收口后耗时下降约96%，锁持有时间同步缩短 – 日锁等待次数: 收口前 15000次, 收口后 320次; 说明=锁等待次数与事务耗时高度正相关 – 接口成功率: 收口前 96.5%, 收口后 99.9%; 说明=事务变短后超时率大幅降低，用户体验改善 说明: 这张图用“事务耗时”与“锁等待次数、接口成功率”的联动关系说明短事务的收益是关联性的。
当系统流量开始增长，单条SQL的性能天花板会逐渐逼近。此时各种并发问题就会出现，比如超卖、重复扣减、锁等待激增。这个阶段要综合运用乐观锁、缓存、分布式锁和最终一致性机制，不要只选一种方案，它们各自有各自的角色。
我把两种方案对比成不同场景下的选择：
version字段，每次UPDATE带上WHERE version = #{oldVersion}，影响行数为0时重试。库存操作的冲突率在10%以下时，这个方案效率最高。我推荐优先用乐观锁，因为它实现简单、并发性能更好。只有当你的业务对“一次操作必须成功、不能重试”有硬性要求时，才考虑悲观锁。实际项目里，90%的库存场景用条件更新加乐观锁就足够了，不需要上悲观锁。
另外需要说明一点，乐观锁带来的是失败重试的成本，悲观锁带来的是等待阻塞的成本，你需要根据业务读多还是写多来权衡到底接受哪一种成本。
单条SQL的性能再快，数据库的TPS也有上限。当秒杀流量超过数据库承受能力后，可以在Redis里做预扣减，为数据库挡掉第一波超卖流量。Redis预扣通常分成四步：
这套方案的关键，不是“Redis扣库存”，而是“Redis和数据库最终一致”。Redis是闸门，数据库是账本。Redis里的预扣记录要在数据库扣减成功后才算真正有效，如果数据库扣减失败，需要有一个定时任务扫描差异并回补Redis的数据。
订单锁定库存后，如果用户一直不付款，锁定库存就是死库存。因此需要定时处理超时未支付的订单：
这里的核心原则是：凡是异步流程，都必须有补偿任务兜底。没有兜底机制，时间一长库存数据必然漂移，这就直接导致以后的“对不上账”问题。
如果是多个应用实例同时操作同一个SKU，比如同时有下单服务和补货服务在改库存，那就需要一把跨进程的锁。但分布式锁解决的是“跨实例互斥”，不是“跨事务一致性”。库存数据的一致性还是要靠事务和条件更新来保证，不能依赖分布式锁。
在实现时，要注意分布式锁的粒度，最好按“sku_id + warehouse_id”维度加锁，锁的粒度越小，并发度越高。锁的过期时间必须大于业务最大执行时间，否则业务还没执行完锁就自动释放，其他线程照样进入临界区。如果你们有Redis集群，要考虑锁的可重入性和续期机制，不要用一个裸SETNX就上生产。
类型: 对比柱状图 标题: 三种并发控制方案在库存场景下的性能对比 插入位置: 本段之后 证据角色: 风险边界 数据来源: 基于相同库存表结构、相同机器配置下的压测基准对比，属于样本推演数据 指标: – TPS吞吐量: 乐观锁 2600, 悲观锁 800, Redis预扣减 5000; 说明=Redis预扣减吞吐最高但依赖后续异步对账链路 – 平均响应时间: 乐观锁 35毫秒, 悲观锁 95毫秒, Redis预扣减 15毫秒; 说明=悲观锁的排队等待直接拉长响应时间 – 数据差异暴露周期: 乐观锁 无差异, 悲观锁 无差异, Redis预扣减 6小时; 说明=Redis方案若异步链路故障，差异可能延迟暴露 说明: 这张图帮助读者理解“选型没有银弹”，Redis高吞吐背后需要额外关注补偿工具的完善度。
库存系统运行六个月后，流水表的增长会逐渐拖慢所有查询。很多团队这时候才想起来“治理数据”，但为时已晚。库存数据的生命周期管理要提前设计，而且这一步不属于“可做可不做”，而属于“迟早必须做”。
核心思路是：库存主表只保留“可用、锁定、已售”三个结果状态，流水表只保留近三个月的热数据，超过三个月的流水按月归档到历史库。
注意这里不是简单的“删数据”，而是“搬数据”。财务对账、订单追溯、纠纷处理都需要至少一年的流水记录。归档的流水进入历史表，仍然支持查询，只是不再参与线上业务事务，避免拖垮主库性能。
归档表和原流水表结构一致，只是表名不同，比如stock_flow_2024_06。为了便于跨月查询，可以建一个视图，让应用层无感知。
归档策略建议按月执行：每月1日凌晨，将stock_flow中created_at早于三个月的记录，分批INSERT到归档表，再DELETE原表记录。大批量DELETE要分批执行，每批5000条，避免产生超大事务导致主从延迟飙升。
— 按月归档库存流水: 分批迁移历史数据
INSERT INTO stock_flow_2024_06
SELECT * FROM stock_flow
WHERE created_at < '2024-04-01 00:00:00'
AND created_at >= '2024-03-01 00:00:00'
LIMIT 5000;— 归档完成后分批清理原表数据
DELETE FROM stock_flow
WHERE created_at = '2024-03-01 00:00:00'
LIMIT 5000;归档任务要放在业务低峰期执行，比如凌晨两点到五点。如果删除速度太慢，建议用分区表替代DELETE，直接把整个分区DROP掉，速度可以提升10倍以上。
保留周期取决于两个因素，一是财务审计要求，二是业务纠纷追溯时间。我的建议是：
各团队需要根据自身行业的合规要求调整，不要照搬。但原则是一致的：“在线库瘦身、离线库存档”，让查询性能和合规要求同时得到满足。
流水归档后，运营想在后台查去年同期的库存变化，怎么办？这是一个很常见的实际需求。如果直接用归档表查询，耗时可能很长，因为归档表没有按时间和SKU建立足够好的索引策略。
我的建议是：归档表只支持“单SKU + 时间范围”的查询，不提供多SKU聚合分析。一旦需要跨SKU按月维度做经营分析，数据要进入分析型数据库，而不是在线MySQL。这样在线库保持轻量，归档库保持可查，分析库保持高效。三种角色各干各的，互不拖累。
类型: 斜率图 标题: 库存流水表数据量增长与查询耗时在冷热分离前后的变化趋势 插入位置: 本段之后 证据角色: 长期趋势 数据来源: 基于零售项目流水表1.2亿行数据的归档前后观测，属于实际项目数据推算 指标: – 在线流水表数据量: 归档前 1.2亿行, 归档后 2400万行; 说明=归档后在线表只保留热数据，查询基数大幅缩减 – 带时间条件的库存查询耗时: 归档前 2.8秒, 归档后 0.4秒; 说明=热数据基数缩小后索引效率明显提升 – 备份耗时: 归档前 2小时, 归档后 25分钟; 说明=在线表变小后备份效率同步提升，运维风险降低 说明: 这张图直接对应“生命周期优化”一节的核心观点，冷热分离让在线库“减肥”，所有查询和运维指标同步改善。
所有优化动作都上线后，最重要的工作不是结束，而是验证和持续监控。没有监控的优化方案是没有反馈的，就像闭着眼开车。这一步要解决“怎么知道优化有效、怎么防止未来回潮”的问题。
监控并不需要一次接入很多内容，只需要先盯住五个直接影响库存业务体验的指标：
这五类指标覆盖了数据库性能、并发健康、数据一致性三个核心维度，信息密度比较大，告警规则建议先设置宽松阈值，观察两周后再收紧，避免误报疲劳。
所有优化代码上线之前，按下面这份清单逐项检查，这一条清单能解决大部分线上事故：
这份清单需要被产品经理、后端开发和测试共同确认，不只是开发自检。我在实际项目中遇到过一次因为没确认回滚方案导致线上库存异常45分钟的案例，从此把这份清单设为发布前置条件。
上线一周后，用之前记录的基线数据对比，输出一份简洁的复盘报告，建议包含以下五部分内容：
我把这个复盘模板压缩成“一页纸清单”，在文档末尾会附上核心内容。建议你直接打印出来贴在工位上，每次做完优化都过一遍。
类型: 横向条形图 标题: 监控验证阶段观察到的关键指标变化幅度汇总 插入位置: 本段之后 证据角色: 下游结果 数据来源: 基于多个项目的复盘记录，整理为观察区间数据，属于建议基准 指标: – P99耗时降幅: 45% 至 85%; 说明=降幅取决于优化前基线水平，基线越差收益越明显 – 锁等待次数降幅: 60% 至 95%; 说明=事务收口是锁等待下降的主要驱动力 – 超卖次数降幅: 70% 至 100%; 说明=条件更新加乐观锁基本可以杜绝超卖 – 对账差异率降幅: 30% 至 90%; 说明=差异率下降受历史坏账数量影响，需要持续跑批清理 说明: 这张图用于展示观察区间，避免读者对优化效果产生不切实际的预期。
下面这份清单是全文模板的压缩版。你不需要再翻前面的章节，只要按这个顺序执行，就能把一套库存数据优化项目完整跑完。建议直接复制到团队文档里，作为每次库存改动前的固定流程。
执行顺序和自检项如下：
WHERE available >= #{num}，是否在事务内操作。这份清单的价值不只是“查漏”，更重要的作用是统一团队成员对库存优化的认知框架。我之前给某零售企业做内训时，把这10项印在一页纸上，后端团队每周五的复盘会逐项过一遍，三个月后线上库存问题工单从每月12个降到了2个。
现在，你可以做的下一步动作是：把这篇文章里的表结构SQL和监控指标清单发给你的技术负责人，约一次30分钟的专项讨论。不要等系统出了问题再救火，而是用这份模板主动给库存数据做一次“体检”。如果你在实施中遇到了模板覆盖不到的问题，大概率是你的业务有一定的特殊约束，比如强批次管理、强效期管理或负库存允许，这些都是模板的下一次迭代方向。
最后强调一遍我的核心观点：库存数据优化不是一条SQL的事，也不只是一次加索引的事，它是一套从模型、事务、并发、生命周期到监控的完整工程。你真正要交付的，不是某一次优化，而是一套让库存数据长期保持“说得清、查得快、对得上”的工作方法。这套模板就是帮你建立工作方法的起点。
读者评论
我们公司之前就是只改SQL，结果过段时间又慢回去。文章说先梳理模型再优化SQL，这个思路确实对，打算按六步模板试一次，特别是先做库存清单盘点。
作为DBA，见过太多库存表被当成普通表优化的情况。文中提到的“库存数据本质是高频写、强一致、实时读”很到位，对账差异率从0.8%降到0.05%这个数据很有说服力。
最有感触的是误区部分，特别是分库分表不是万能药这点。我们日订单量不大，但之前也总想分库分表，其实先把表结构和SQL优化好能提升好几倍，这篇文章帮我避坑了。
模板里的事务边界收口思路很实用，我们库存锁等待严重，就是因为事务里查了太多东西。看完后把事务精简到只保留扣减操作，锁等待次数明显下降，推荐同行参考。
流水表膨胀问题一直头疼，不敢删又影响性能。文中提到做生命周期管理，把热冷数据分开，这个方向很对。希望模板能再细化一下具体归档策略。