《数据库存：电商企业年度规划：表结构设计怎样持续改善提升查询性能》真正要解决的，不是“库存表该增加哪些字段”，而是当 SKU、仓库、订单和库存流水持续增长时，数据库怎样仍然能够稳定回答三个问题：现在还有多少库存、库存为什么发生变化、未来一段时间会不会不够用。我的判断是，电商企业最容易犯的错误，是把一次性的表结构设计当成年度数据库规划；实际上，表结构必须随着查询路径、数据增长速度和业务一致性要求持续调整。
很多系统在上线初期运行良好，半年后却出现库存列表加载慢、报表查询拖慢订单接口、同一个 SKU 在不同页面显示数量不一致等问题。此时，团队通常先加索引、加缓存，甚至直接讨论分库分表。但如果没有先区分主数据、当前库存、库存流水和统计数据，这些动作往往只能缓解症状，无法改变问题的根因。
索引当然重要，但它只解决了一部分问题。一次库存查询的实际耗时，可能同时受到表结构、过滤条件、排序方式、关联数量、锁等待、返回数据量、数据冷热分布和数据库资源的影响。
例如，下面这条查询即使在 sku_id 上建立了索引，也不一定能够稳定运行：
SELECT * FROM inventory_transaction WHERE sku_id = 10086 AND DATE(occurred_at) = '2026-09-16' ORDER BY occurred_at DESC;
问题在于，对时间字段使用 DATE() 函数后，数据库可能无法有效利用原有的时间索引；同时，SELECT * 会读取大量并不需要的字段。更适合在线查询的写法通常是明确时间范围，并只返回页面需要的字段。
SELECT id, transaction_type, quantity, reference_type, reference_id, occurred_at FROM inventory_transaction WHERE sku_id = 10086 AND occurred_at >= '2026-09-16 00:00:00' AND occurred_at < '2026-09-17 00:00:00' ORDER BY occurred_at DESC LIMIT 50;
我的经验是，先改查询路径，再决定索引；先确认数据职责，再决定是否拆表。直接堆索引，可能让读取变快，却让入库、出库和盘点更新变慢。
“当前还剩多少”与“库存为什么变化”是两种完全不同的查询。前者要求低延迟和高并发，后者要求可追溯、可审计和支持时间范围检索。
| 数据对象 | 主要回答的问题 | 典型访问方式 | 性能重点 |
|---|---|---|---|
| SKU主数据 | 这是什么商品、什么规格 | 按编码、名称、分类查询 | 稳定关联、检索效率 |
| 库存余额 | 现在还有多少可用、预占和冻结库存 | 按SKU和仓库点查 | 低延迟、高并发、更新一致性 |
| 库存流水 | 库存为什么增加或减少 | 按单据、SKU、仓库和时间追溯 | 写入吞吐、时间检索、归档能力 |
| 库存汇总 | 某日、某月的库存趋势怎样 | 按周期和组织汇总 | 避免扫描在线交易表 |
如果把这四类信息放入一张表，初期看起来字段少、开发快，后期却容易出现三类冲突：库存余额更新与历史流水写入互相影响，运营报表与在线接口争抢资源，字段含义随着业务变化不断膨胀。
数据库年度规划不应以“今年新增多少张表”为目标，而应以核心业务查询是否可预测、可监控、可回滚为目标。库存系统至少要明确以下查询路径：
每一种查询都应对应明确的数据来源、索引策略、数据新鲜度和性能目标。只有这样，表结构优化才不会变成脱离业务的数据库“装修工程”。
在单仓库、SKU较少、订单量有限的阶段，一张包含 SKU、仓库、可用数量、锁定数量和更新时间的库存表，完全可能满足业务需求。此时查询条件简单，数据量可控，开发团队也能够通过事务保证库存扣减。
问题不在于“一张表起步”本身，而在于企业没有为下一阶段留下清晰的演进路径。很多团队把临时方案直接固化成永久模型，后来再把采购、调拨、退货、批次、库位和库存冻结都塞进同一张表。
电商企业的增长通常不是简单地增加订单行数。业务变化会同步改变查询维度：从单仓库变成多仓库，从商品级库存变成 SKU 级库存，从总库存变成可售、预占、冻结和质检库存，从实时查询变成实时交易加历史分析。
举个情景案例。某企业第一年只有 1 个仓库、约 2 万个 SKU，每天约 1.5 万笔订单；第二年增加到 6 个仓库、12 万个 SKU，日订单约 9 万笔，并开始支持调拨、组合商品和退货重入库。此时，原来的“按 SKU 查询库存”已经变成“按 SKU、仓库、库存状态和渠道共同判断可售量”。
如果表结构仍然只保留一个 stock_qty 字段，系统就必须把预占、冻结、待质检和可售数量通过临时计算拼接出来。随着并发增加，计算逻辑和更新逻辑会变得越来越难以验证。
我见过一种很典型的设计：库存表中同时有商品名称、供应商名称、仓库名称、可用库存、累计入库量、累计出库量、最近一次盘点数量、最近操作人和备注字段。运营人员查询方便，但每次商品名称、仓库名称或供应商资料变化，都可能触发大量冗余数据更新。
这种设计还会制造“看起来很快，实际不稳定”的假象。简单点查可能只需几十毫秒，但一旦执行跨月统计、模糊搜索或多仓库汇总，数据库就需要扫描和排序大量历史数据。
在实际项目中，我通常会把业务数据库和分析层分开看。像九数云这类数据分析平台，适合连接多源业务数据、制作经营看板和进行库存趋势分析；它可以减少运营人员直接在交易库上运行复杂报表查询的需求。
但这并不意味着分析平台能够修复交易库中不合理的表结构。SKU与仓库关系没有定义清楚、库存流水缺少业务单据号、时间字段含义不统一，这些问题即使进入分析层，也只会变成更难排查的数据口径问题。
因此，我会把九数云放在“报表消费和经营分析”这一层，而不是把它当成库存余额表或事务数据库的替代品。官网信息可参考：九数云。
索引不是免费的。每次库存余额更新、流水写入或批量盘点，都需要维护相关索引。索引数量过多会增加磁盘占用、写入放大和优化器选择成本。
尤其是状态字段、布尔字段和低基数字段，单列索引通常未必有效。例如库存状态只有“正常、冻结、质检”三种取值，单独给 stock_status 建索引，可能无法明显减少扫描行数。
更重要的是，索引必须匹配真实查询。一个适合“按仓库和 SKU 点查”的索引，不一定适合“按仓库筛选低库存并按更新时间排序”的列表查询。
冗余字段有时能够减少关联，但它会带来同步一致性成本。如果商品改名后库存表没有同步更新，运营页面和商品主数据就会出现不一致。
我的判断标准不是“是否允许冗余”，而是区分冗余字段的用途。用于展示且变化很少的快照字段，可以有条件地保留；用于业务判断的核心字段，最好以稳定 ID 作为关联依据，不能依赖可变文本。
如果每次商品详情页打开都通过流水汇总当前库存，系统会把一个本应是点查的问题，变成对大表的聚合问题。随着流水记录增长，查询耗时和资源消耗会持续放大。
更稳妥的设计是：库存流水记录事实，库存余额保存当前状态。每次库存变更在同一业务事务中更新余额并写入流水，或者通过可靠消息机制最终完成汇总，同时保留对账和重算能力。
这种方式看起来少了一层数据链路，但代价是在线交易和分析查询共享数据库资源。月度库存统计可能需要扫描数千万条流水，恰好与大促期间的订单扣减争抢 CPU、IO 和连接数。
如果报表允许存在一定延迟，应该考虑汇总表、分析库或数据分析平台。关键不在于“是否实时”，而在于明确报表数据的更新时间和业务可接受的延迟。
分库分表会引入跨分片查询、分布式事务、全局 ID、数据迁移、扩容和运维监控等新问题。对于数据量尚小、单库资源尚有余量的企业，过早拆分可能让开发和排障成本大于性能收益。
通常我会建议先完成表职责拆分、慢查询治理、冷热数据分层和报表隔离，再根据真实容量和压测结果判断是否需要分片。架构复杂度本身也是一种成本，不能只看理论吞吐量。
事实是已经发生的事件，例如一次入库、一次出库、一次盘点调整；状态是当前时点的结果，例如某 SKU 在某仓库的可用库存；结果是对事实进一步计算出来的指标，例如月度出库量、库存周转天数和缺货率。
三者可以相关，但不应默认存储在同一张表中。事实表追求完整和不可随意修改，状态表追求快速读取，结果表追求计算效率和口径稳定。
| 判断对象 | 适合保存的内容 | 通常的更新方式 | 不适合承担的职责 |
|---|---|---|---|
| 主数据表 | 商品、SKU、仓库、供应商 | 低频变更 | 保存库存变化历史 |
| 状态表 | 可用、预占、冻结数量 | 高频更新 | 替代完整审计流水 |
| 事实流水表 | 入库、出库、调拨、退货 | 持续追加 | 承载高频在线点查 |
| 汇总结果表 | 日、月、仓库和 SKU 汇总 | 定时或异步更新 | 作为实时库存唯一来源 |
下单扣减库存和管理层查看月度库存趋势，不能使用同一套一致性标准。下单校验通常要求较强的一致性，不能因为报表延迟而多卖；月度报表则通常允许分钟级甚至小时级延迟。
如果所有数据都要求实时，系统会承担更高的事务、锁竞争和同步成本。如果所有数据都采用异步汇总，又可能无法满足交易场景。设计时应先按业务风险分类，而不是追求一个笼统的“全链路实时”。
组合索引的字段顺序不能只依赖经验口诀。需要从真实 SQL 出发，观察哪些字段是等值过滤、哪些字段是范围过滤、是否需要排序、返回行数有多少，以及数据分布是否均匀。
例如，库存流水常见查询可能是按仓库、SKU和时间范围检索：
SELECT id, transaction_type, quantity, occurred_at FROM inventory_transaction WHERE warehouse_id = 12 AND sku_id = 10086 AND occurred_at >= '2026-09-01 00:00:00' AND occurred_at < '2026-10-01 00:00:00' ORDER BY occurred_at DESC LIMIT 100;
对于这类查询，可以评估以 warehouse_id、sku_id、occurred_at 为核心的组合索引，但具体顺序仍要通过数据库执行计划和真实数据分布验证。不能把示例索引原封不动复制到所有系统。
库存流水如果每天新增数十万或数百万行，三年后在线表的体量会完全改变查询特征。年度规划必须在表结构设计阶段就回答：哪些数据是热数据、哪些数据进入历史库、历史数据是否需要秒级查询、归档任务何时运行。
我建议把保留策略写成可执行规则，例如“在线流水保留近 12 个月，超过 12 个月进入历史库；月度汇总保留 5 年；原始审计记录按合规要求保留”。这比笼统地写“定期清理历史数据”更有操作价值。
SPU更适合表示商品款式或产品族，SKU则表示可以独立销售、定价和扣减库存的具体规格。库存通常应该落在 SKU 维度，因为“白色、L码”和“黑色、M码”可能拥有完全不同的库存数量。
CREATE TABLE product_spu (
id BIGINT PRIMARY KEY,
product_name VARCHAR(200) NOT NULL,
category_id BIGINT NOT NULL,
status TINYINT NOT NULL,
created_at DATETIME NOT NULL,
updated_at DATETIME NOT NULL
);
CREATE TABLE product_sku (
id BIGINT PRIMARY KEY,
spu_id BIGINT NOT NULL,
sku_code VARCHAR(64) NOT NULL,
specification JSON NULL,
status TINYINT NOT NULL,
created_at DATETIME NOT NULL,
updated_at DATETIME NOT NULL,
UNIQUE KEY uk_sku_code (sku_code),
KEY idx_spu_status (spu_id, status)
);这里有两个需要特别注意的细节。第一，SKU编码应保持稳定，不能把商品名称当作关联键；第二，如果使用 JSON 保存规格，应明确哪些属性需要参与筛选，频繁检索的属性最好抽取为结构化字段或建立适配数据库能力的索引。
“库存数量”是电商系统中最容易产生歧义的字段之一。可用库存、物理库存、预占库存、冻结库存和待质检库存的业务含义不同。如果所有数量都叫 stock_qty，后续每个接口都可能自行解释。
CREATE TABLE inventory_balance (
id BIGINT PRIMARY KEY,
sku_id BIGINT NOT NULL,
warehouse_id BIGINT NOT NULL,
on_hand_qty DECIMAL(18, 4) NOT NULL DEFAULT 0,
reserved_qty DECIMAL(18, 4) NOT NULL DEFAULT 0,
frozen_qty DECIMAL(18, 4) NOT NULL DEFAULT 0,
available_qty DECIMAL(18, 4) NOT NULL DEFAULT 0,
version BIGINT NOT NULL DEFAULT 0,
updated_at DATETIME NOT NULL,
UNIQUE KEY uk_warehouse_sku (warehouse_id, sku_id),
KEY idx_warehouse_available (warehouse_id, available_qty, updated_at)
);是否保留 available_qty 这一冗余结果，要看系统的一致性要求。如果每次读取都实时计算，可能增加读取成本；如果直接保存，则必须保证扣减、释放和冻结逻辑能够在同一事务或可靠事件链路中更新。
我更关注数量字段之间是否存在可验证的关系，而不是字段越少越好。例如可以建立对账规则，定期检查物理库存、预占库存、冻结库存与可用库存之间是否符合业务公式。
流水表的价值在于记录变化过程。入库、销售出库、仓间调拨、退货、盘点调整和人工修正，都应该有明确的交易类型、业务单据号、发生时间和操作来源。
CREATE TABLE inventory_transaction (
id BIGINT PRIMARY KEY,
sku_id BIGINT NOT NULL,
warehouse_id BIGINT NOT NULL,
transaction_type VARCHAR(32) NOT NULL,
quantity DECIMAL(18, 4) NOT NULL,
reference_type VARCHAR(32) NOT NULL,
reference_id VARCHAR(64) NOT NULL,
occurred_at DATETIME NOT NULL,
operator_id BIGINT NULL,
created_at DATETIME NOT NULL,
KEY idx_wh_sku_time (warehouse_id, sku_id, occurred_at),
KEY idx_reference (reference_type, reference_id),
KEY idx_occurred_at (occurred_at)
);流水表不建议只保存一个正负数量，却不保存交易类型。负数能够表达减少，但不能说明减少的原因；没有原因，就无法支持异常排查、财务核对和责任追踪。
订单创建并不一定等于实际出库。用户下单后可能未支付，支付后可能拆单，仓库可能缺货，退货也可能重新进入待质检状态。将订单数量直接写入库存扣减字段，会把不同业务阶段混成一个状态。
建议至少区分订单需求、库存预占和仓库实际出库。这样即使订单取消，也可以释放预占；实际出库则通过仓储单据产生库存流水，而不是简单修改订单表中的某个库存字段。
库存流水可以回答“发生了什么”，但不一定能够高效回答“某个历史日期结束时还剩多少”。如果企业经常进行月末盘点、资金占用分析或历史库存复盘，可以建立按日或按月的库存快照。
快照表应该明确生成时间、统计口径和是否经过对账。否则，团队可能误把实时余额倒推结果当成历史真实状态，最终导致报表数字无法解释。
我在做性能治理时，不会先打开表结构页面寻找“还缺哪个索引”，而是先收集接口和 SQL。至少要记录查询用途、调用频率、峰值并发、平均耗时、P95耗时、扫描行数和返回行数。
| 查询场景 | 主要条件 | 优先观察指标 | 可能的优化方向 |
|---|---|---|---|
| SKU仓库库存点查 | warehouse_id、sku_id | P95耗时、锁等待 | 唯一约束、精确点查、缩小返回列 |
| 低库存列表 | warehouse_id、available_qty、status | 扫描行数、排序耗时 | 组合索引、分页方式、预警汇总 |
| 订单库存追溯 | reference_type、reference_id | 单据查询耗时 | 业务单据索引、幂等约束 |
| 按月流水统计 | occurred_at、warehouse_id | 聚合耗时、IO | 时间分区、汇总表、分析层隔离 |
假设最常见的查询是“某仓库中某 SKU 在指定时间段内的库存流水”，那么仓库、SKU和时间范围就应成为索引设计的候选字段。假设最常见的查询改成“某仓库所有低库存 SKU，并按照最近更新时间排序”，索引方案又会不同。
这说明不存在脱离 SQL 的通用最优索引。字段基数、数据分布、查询频率和排序需求都需要纳入判断。一个在测试数据上有效的索引，换到生产数据后也可能因为数据倾斜而失效。
状态、是否删除、是否冻结等字段通常只有少数几种取值。单独依赖这些字段过滤，数据库仍然可能需要读取大量记录。更合理的方式是结合业务范围字段，例如仓库、组织、时间或 SKU 维度进行组合。
不过，组合索引也不是越长越好。字段越多，写入成本和索引体积越高，而且 SQL 稍微改变，索引就可能无法覆盖主要路径。我的建议是为每个核心查询保留最小有效索引，而不是为所有可能条件提前做排列组合。
很多运营后台使用 LIMIT 100000, 50 读取很深的分页。数据库即使最终只返回 50 行，也可能先扫描和丢弃前面的 10 万行。数据量大时，页码越深，响应越不稳定。
如果列表可以按照稳定的递增 ID 或更新时间翻页，可以采用基于游标的方式：
SELECT id, sku_id, warehouse_id, available_qty, updated_at FROM inventory_balance WHERE warehouse_id = 12 AND id < 900000 ORDER BY id DESC LIMIT 50;
这种方式要求排序字段稳定，并且前端保存上一页的游标。它不适用于用户必须随机跳转到任意页码的所有场景，但对于后台滚动加载、流水追溯和日志列表通常更稳定。
执行计划中的估算行数并不等于实际行数。统计信息过期、数据分布不均或参数变化，都可能让优化器选择并不理想的执行路径。因此，索引上线前后要对比真实数据下的执行计划和实际耗时。
我通常会至少观察以下内容：
下面这个案例是我根据电商库存系统常见问题整理的情景模拟，不对应某一家企业的生产数据。企业有 6 个仓库、约 12 万个 SKU，日均订单 9 万笔，库存流水保留 24 个月。
原系统只有一张核心库存表，既保存当前数量，也保存入库累计量、出库累计量、盘点差异和最近一次操作信息。商品详情页、仓库后台和经营报表都直接查询这张表。
系统最初的症状并不是所有接口都慢，而是高峰时段出现明显分化：SKU点查仍然可以完成，低库存列表开始出现秒级响应，月度出入库报表则经常需要几十秒甚至更长时间。
团队把过去 14 天的慢查询按照接口归类，发现最耗资源的并不是调用次数最多的 SQL，而是执行频率不高、每次扫描范围很大的报表查询。它们在业务高峰期与订单接口共享连接池和数据库 IO。
| 查询类别 | 调用特征 | 主要瓶颈 | 处理策略 |
|---|---|---|---|
| 库存点查 | 调用次数高、单次数据少 | 锁等待和连接竞争 | 余额表精确查询、缩短事务 |
| 低库存列表 | 中频、带筛选和排序 | 扫描行数与排序 | 组合索引、游标分页 |
| 月度报表 | 低频、扫描范围大 | 聚合和IO资源争抢 | 汇总表或分析层 |
| 订单追溯 | 偶发、需要关联单据 | 单据索引缺失 | reference索引和时间条件 |
改造后，库存余额表只保留 SKU、仓库、物理库存、预占库存、冻结库存、可用库存、版本号和更新时间。商品展示不再读取流水表，订单校验也不再执行流水聚合。
库存流水表则保留每一笔变更的交易类型、数量、来源单据、发生时间和操作人。每个业务事件都携带幂等标识，避免消息重试或接口重复调用造成重复扣减。
这一步的关键收益不是某条 SQL 少了几个字段，而是让高频读写和低频历史查询不再争抢同一条访问路径。
月度报表不再直接扫描在线流水表，而是按日生成仓库、SKU和交易类型的汇总数据。对于需要更复杂的经营分析，可以把汇总结果同步到分析层，再由九数云等工具制作管理看板。
这里必须定义数据新鲜度。例如，库存余额要求接近实时，日汇总可以每天凌晨生成，经营看板则可以每小时刷新。只要在页面上清楚标注统计时间，业务人员就不会把两个不同时间点的数字误认为系统冲突。
改造验收至少包含三个场景：正常工作日、促销高峰和历史报表同时运行。测试不应只看一台机器上的平均 SQL 耗时，而要观察整个接口链路的 P95、P99、数据库 CPU、IO、锁等待和连接池占用。
在这个情景案例中，经过结构拆分、索引调整、游标分页和报表隔离后，库存点查的平均响应时间从 180 毫秒下降到 72 毫秒，P95 从 640 毫秒下降到 155 毫秒；月度报表从直接扫描在线表改为汇总表读取，执行时间从约 38 秒降至 4 秒左右。
这些数字属于案例模拟，不能直接作为任何企业的承诺。它们的意义在于说明：不同问题需要不同手段，不能把所有性能收益都归功于“增加了一个索引”。
第一季度不建议急于拆表。此阶段最重要的工作，是让团队知道系统当前到底慢在哪里，以及哪些查询对业务影响最大。
如果没有基线，后续的“优化成功”往往只是主观判断。建议至少保留优化前两周的监控数据，并按正常时段、业务高峰和批处理时段分别统计。
第二季度重点解决表职责混杂和核心查询不稳定的问题。可以先从库存余额、库存流水、SKU主数据和仓库关系入手，不要一开始就重构整个订单系统。
如果使用在线 DDL 或类似能力，也不能假设变更完全没有风险。大表加索引仍可能消耗 IO、影响复制延迟或增加锁竞争，必须在接近生产的数据规模上先验证。
第三季度通常接近大促或业务高峰，是检验数据库规划是否有效的阶段。此时应重点处理流水增长、报表隔离和突发并发。
热点 SKU 是一个容易被忽略的问题。即使总订单量不算特别大，某个爆款 SKU 也可能被大量订单同时扣减，导致同一库存行成为锁竞争热点。这个问题不是增加普通查询索引就能解决，必须结合库存预占策略、分段库存、队列化扣减或业务限购规则判断。
第四季度要做的不是再写一份“系统运行良好”的总结，而是把一年中的真实数据转化为下一年度的架构判断。
这类企业通常不需要马上分库分表。优先工作应是把 SKU、仓库、库存余额和流水的职责定义清楚，并建立慢查询监控。
这里的取舍是：用较简单的单库架构换取开发和运维成本可控，同时通过职责拆分为未来扩展留下空间。
这类企业最应该优先做的是库存余额和库存流水分离、报表层隔离、归档规划和高峰压测。很多系统在这个规模已经能够运行，但稳定性开始依赖数据库参数和人工经验。
这类企业的核心取舍，是不能只追求实时性。交易数据需要强一致，管理报表可以接受延迟，分层后系统反而更稳定。
这类企业需要把库存系统当成独立的交易能力来规划，而不是订单系统中的一张附属表。除了基础表结构，还要考虑库存域、仓储域、订单域和分析域之间的边界。
这类企业不能只看查询速度，还要考虑故障时是否能够恢复库存事实。没有流水、快照和对账能力的“高性能库存表”，在出现异常后会非常难以修复。
如果企业当前主要痛点是库存周转、销售预测、仓库效率和资金占用分析，而不是下单扣减，那么可以优先建设稳定的数据出口和分析层。
此时，九数云这类平台可以帮助业务人员整合商品、订单、库存和仓储数据，减少手工导出和表格拼接。但在接入之前，仍需要统一 SKU 编码、仓库编码、日期口径和库存数量定义，否则看板只是把不一致的数据展示得更漂亮。
慢查询不能只在系统出故障后临时处理。建议形成固定流程：自动采集、业务归类、影响评估、执行计划分析、方案变更、灰度验证和结果复盘。
CPU占用下降不代表库存接口一定变快。数据库可能 CPU 不高，却因为锁等待、连接池耗尽、磁盘延迟或复制延迟导致业务超时。
| 指标类别 | 建议指标 | 为什么要看 |
|---|---|---|
| 接口体验 | 平均耗时、P95、P99、超时率 | 识别尾延迟和用户实际感受 |
| 查询执行 | 扫描行数、返回行数、临时排序 | 判断 SQL 是否读取了过多数据 |
| 并发资源 | 锁等待、连接池占用、活跃事务 | 识别高峰期竞争和事务过长 |
| 存储容量 | 表大小、索引大小、增长率、磁盘延迟 | 支持归档和扩容决策 |
| 数据可靠性 | 对账差异、消息积压、复制延迟 | 避免只追求速度而忽略库存正确性 |
库存表是高频读写对象，任何字段、索引和约束变更，都可能影响在线交易。大表加索引要评估执行时间和磁盘空间，字段改名要考虑旧代码兼容，删除字段要先确认所有上下游已停止使用。
比较稳妥的发布顺序通常是：先发布兼容新旧结构的代码，再增加新字段或索引，完成数据回填与验证，最后切换读取路径，观察稳定后再删除旧字段。对于无法快速回滚的变更，应提前准备备份、补偿脚本和降级方案。
应用代码再严密，也可能遇到重复消息、网络超时、人工修正、批量导入或外部仓储系统回调异常。库存余额表和流水表之间应有定期对账机制。
对账不一定每次都重算全部历史数据，可以按仓库、SKU和时间窗口分批执行。发现差异后，要能够追溯到业务单据、操作人和事件处理记录，而不是直接把余额改成一个“看起来正确”的数字。
如果在线查询主要集中在最近 3 个月或 12 个月，而历史流水持续增长，优先做归档通常比直接分库分表更容易控制。归档可以减少在线表体积，降低索引维护和备份压力。
但归档必须回答三个问题：历史数据是否仍可查询，查询入口在哪里，归档过程如何避免重复或遗漏。没有校验和回滚机制的归档，可能把性能问题变成数据完整性问题。
如果查询经常带有明确的时间范围，且数据天然按照时间增长，分区可能有帮助。例如库存流水按月写入，历史查询也经常按月筛选，时间分区能够减少不相关数据的读取范围。
但是，如果大量查询只按 SKU 查询而不带时间条件，分区未必能够带来预期收益。分区键必须与主要访问路径匹配，不能因为“大表就应该分区”而机械实施。
当库存写入和在线读取都很频繁，且一部分查询可以接受短暂延迟时，可以评估只读副本或分析副本。需要注意的是，库存扣减后的立即读取可能遇到复制延迟，不能把所有读取都无条件导向副本。
读写分离的前提是业务能够识别哪些查询必须读主库、哪些查询允许读副本，并且具备复制延迟监控。否则，架构扩展后可能出现“刚扣减库存，页面仍显示旧数量”的用户投诉。
只有当单库在容量、IO、连接数、锁竞争或故障恢复时间上已经接近明确边界，且常规优化无法解决时，才应认真评估分库分表。
分片键的选择尤其关键。按仓库分片可能方便仓库内部查询，却让跨仓库库存汇总复杂；按 SKU 分片可能改善商品维度访问，却使某些订单跨多个 SKU 时需要协调多个分片。分片不是纯技术动作，而是对业务查询和故障域的重新分配。
电商库存数据库设计的核心，不是追求一套“永远不会变”的表结构。业务会增加仓库、渠道、批次和库存状态，查询也会从简单点查逐步扩展到追溯、统计和预测。试图用一张表、一个索引或一次分库分表解决未来所有问题，本身就是不现实的。
我更认可一种渐进式路线：先区分主数据、当前状态、业务事实和统计结果；再根据真实查询设计索引；随后处理流水增长、历史归档和报表隔离；最后依据监控基线和压测数据判断是否需要更复杂的架构。
下一步可以先做三件事：导出近两周最慢的库存相关 SQL，画出 SKU、仓库、余额、流水和订单之间的关系，再把每条核心查询对应到明确的数据表和性能指标。完成这三步后，团队通常就能看出问题究竟是索引不足、表职责混杂、报表隔离缺失，还是库存并发模型本身需要调整。
如果年度规划只能保留一个目标，我建议不要写“提升数据库性能”，而要写成可验证的结果：核心库存接口的 P95 响应时间、库存流水在线数据规模、报表对交易库的访问比例、慢查询数量和库存对账差异率。能够被持续观测、验证和复盘的表结构，才是真正服务于企业增长的表结构。
我现在遇到一个很棘手的问题：商品、仓库、订单、出入库记录都放在一张库存大表里，刚开始查询还算正常，但SKU和订单量增长后，库存列表、盘点报表和订单扣减开始互相影响。我不确定这是索引没建好，还是表结构本身就不合理，究竟应该怎样拆分才不会牺牲库存一致性？
在一次库存系统改造中，我们发现“库存查询变慢”并不是单条SQL的问题，而是一张表同时承担了三种职责：保存当前库存、记录库存变化、支撑历史统计。在线交易需要快速读取当前数量，盘点需要追溯变化过程，报表则需要扫描一段时间的数据，这三类访问路径天然冲突。更稳妥的做法是至少拆成库存余额表和库存流水表。
库存余额表只保存SKU在某个仓库维度下的最新状态，例如可用库存、预占库存、冻结库存和更新时间；库存流水表则记录入库、出库、调拨、退货、盘点调整等每一次变化。
数据对象主要用途访问特点设计重点 商品与SKU表保存主数据读取多、修改相对少SKU编码唯一，避免用商品名称关联 库存余额表查询当前库存高频读取、高频更新以sku_id和warehouse_id建立唯一约束 库存流水表追溯库存变化持续写入、按时间查询记录业务来源和关联单号 库存汇总表支撑运营报表批量读取、复杂统计避免反复扫描在线交易表 库存余额不等于库存流水的简单求和结果。
实际业务中还会涉及幂等扣减、库存预占、订单取消回滚和并发更新，因此余额表通常需要在交易事务中维护，流水表作为审计和追溯依据。这样既能保证在线查询速度，也能在出现差异时还原库存变化过程。我不建议一开始就把商品、仓库、批次、订单和流水拆成几十张表。
拆分的边界应由查询场景决定：凡是更新频率、保留周期和查询目的明显不同的数据，就应该考虑分离；只是为了追求“表越细越专业”而拆表，反而会增加关联查询和事务复杂度。
我已经给库存表加了sku_id、warehouse_id和updated_at等索引，但高峰期查询仍然很慢，有些SQL甚至比没有索引时更不稳定。我想知道组合索引的字段顺序应该怎样判断，以及除了看接口响应时间之外，还有哪些证据能证明优化是有效的？
索引设计不能从“哪些字段都建一个索引”开始，而应该从真实查询路径开始。在库存系统中，最常见的查询通常不是单独按SKU查，而是按仓库、SKU、库存状态过滤，再按更新时间排序或限制返回数量，因此单列索引未必能覆盖完整访问路径。
例如，下面两类查询看起来相似，但适合的索引方向并不完全相同： 查询场景典型条件需要重点评估的索引容易忽略的问题 查询某仓库某SKU库存warehouse_id = ?AND sku_id = ?
warehouse_id、sku_id组合索引或唯一索引需要防止同一SKU同一仓库出现重复记录 查询仓库低库存商品warehouse_id = ?AND available_qty 仓库过滤字段与业务访问方式组合评估数量字段选择性可能较低 查询最近更新库存warehouse_id = ?
ORDER BY updated_at DESCwarehouse_id、updated_at组合索引排序和过滤是否能共同利用索引 追溯订单库存变化reference_type = ?AND reference_id = ?
业务来源类型、来源单号组合索引单纯按时间索引可能无法解决问题 组合索引字段顺序不能机械套用“区分度最高的字段放第一位”。更可靠的判断方式是观察查询中的等值条件、范围条件和排序条件，并用执行计划验证。等值过滤通常可以放在前面，范围条件的位置则需要结合后续排序和覆盖需求测试。
在一次优化中，某库存列表接口原本扫描约180万行，接口平均耗时约1.8秒。我们没有立即增加更多索引，而是先发现SQL对时间字段做了函数转换，导致已有索引无法正常使用。改写时间条件后，扫描行数降到约2.4万行；随后再调整组合索引，平均耗时降到约260毫秒。
这个案例说明，索引失效有时比“缺少索引”更常见。验证索引至少要看四项：执行计划是否选择预期索引、预计扫描行数是否下降、实际返回行数与扫描行数是否接近、是否出现额外排序或临时表。还要在接近生产数据量的环境中测试，因为几千行数据上的优化结果，不能直接推断到几百万行甚至上亿行的场景。
最后要评估索引的写入代价。库存余额表更新频繁，索引数量过多会增加页分裂、写入和维护成本。因此我的判断标准不是“索引越多越好”，而是每个索引都必须对应一个稳定、高频且有业务价值的查询路径。
我们过去的数据库优化基本靠出了问题再处理：接口慢了就加索引，表变大了才临时归档，大促前也没有明确的容量基线。现在公司希望把数据库治理纳入年度规划，但我不清楚每个季度应该安排什么工作，哪些指标才适合用来判断优化是否真正完成？
年度数据库规划不应该写成“第一季度优化SQL、第二季度扩容”这样的任务清单，因为这些动作没有说明问题边界和验收标准。更合理的方式是按数据生命周期和业务风险安排阶段目标：先建立基线，再改造核心路径，接着处理增长带来的容量问题，最后把结果固化为监控和变更流程。
阶段核心目标重点工作建议验收指标 第一季度看清现状盘点表结构、慢查询、数据量和增长速度完成核心表清单，建立响应时间和数据量基线 第二季度优化核心交易路径拆分余额与流水、重构索引、修正高频SQL核心接口P95耗时、扫描行数和慢查询数量有明确变化 第三季度应对增长和高峰归档流水、隔离报表、开展大促压测高峰期锁等待、CPU、IO和错误率处于可接受范围 第四季度复盘与预备扩展评估容量、索引使用、故障记录和下一年度增长形成复盘报告、容量预测和下一年度改造优先级 第一季度最容易被忽略，却是最重要的阶段。
没有基线，就无法判断优化是否有效。建议至少记录核心库存接口的平均耗时、P95和P99耗时、慢查询数量、扫描行数、数据库CPU、磁盘IO、锁等待以及主要表的月增长量。第二季度不要同时改动所有业务表，而应优先处理影响交易的最短路径。
例如先分析“下单校验库存”“查询仓库库存”和“订单出库扣减”三个接口，再决定余额表的唯一键、并发更新方式和组合索引。改动范围越集中，越容易做灰度验证和故障回滚。第三季度的重点不是盲目分库分表，而是把在线交易和历史分析隔离开。
库存流水、订单明细和操作日志往往增长最快，如果报表直接扫描这些在线表，大促期间就可能与交易查询争抢IO。可以先采用按时间归档、汇总表或独立分析库，只有当单库容量和并发边界确实无法满足时，再评估更复杂的拆分方案。
第四季度要把优化从个人经验变成团队机制，包括慢查询自动采集、DDL变更评审、大表加索引方案、发布兼容策略和回滚预案。年度规划的最终成果不是某个接口短暂变快，而是企业能够提前知道数据何时会超过容量边界、哪个查询正在恶化，以及下一次业务增长需要怎样调整表结构。
我们发现库存流水表的增长速度远高于库存余额表，历史数据已经影响到盘点和报表查询。团队里有人建议马上分库分表，也有人认为只要建分区就够了，我担心过早改造会增加运维和事务复杂度，应该用什么标准做选择？
我的经验是，库存流水表变大后，优先处理数据生命周期，通常比直接分库分表更稳妥。因为很多慢查询并不是单纯由表的总行数造成，而是在线查询仍然把多年历史数据当作同一批热数据处理，导致索引膨胀、缓存命中下降和报表扫描范围过大。
可以按照下面的顺序判断： 方案适合场景主要收益主要代价 归档到历史库历史数据访问频率低，但仍需保留降低在线库数据量，实施相对可控跨库查询和数据恢复需要额外流程 按时间分区查询经常带时间条件，数据有明确时间边界便于分区裁剪和分区级维护分区键设计不当时收益有限 汇总表运营报表反复统计日、周、月数据减少对明细流水的重复扫描需要定义刷新频率和延迟边界 分库分表单库容量、写入并发或故障边界已成为瓶颈扩大容量和吞吐边界事务、跨分片查询、运维复杂度明显增加 分区表不是“表变大后的万能按钮”。
如果查询没有带分区键，数据库仍可能访问大量分区；如果分区过多，也会增加优化器和运维管理成本。因此，只有当库存流水主要按发生时间查询，并且能够稳定使用时间范围条件时，按月或按季度分区才值得评估。
在一个脱敏的改造场景中，库存流水在线表保留近十二个月，超过保留期的数据每天凌晨转入历史库，同时按日生成出入库汇总表。报表查询从直接扫描多年明细改为读取汇总数据，在线交易库不再承担重复统计。这个方案没有改变业务接口，也没有引入分片，先解决了最明显的资源争抢问题。
是否需要分库分表，应看三个证据：单库容量是否接近可用上限、写入和查询是否在高峰期持续互相影响、以及纵向扩容和归档后是否仍无法达到目标。如果归档、索引重构、报表隔离和读写优化后，核心指标仍然持续恶化，才有充分理由进入分库分表评估。
无论选择哪种方案，都要先明确数据保留期限、历史查询方式、跨年度统计需求和故障恢复流程。数据库架构改造最常见的坑，是只计算了“能不能拆”，却没有计算“拆完以后谁负责查询、对账、迁移和恢复”。
读者评论
文章把库存余额、库存流水和统计数据分开讨论很实用，尤其是强调先梳理查询场景再设计索引，避免了“索引越多越好”的片面认识。
关于使用时间范围替代DATE函数、避免SELECT *的示例比较具体，能帮助开发人员快速发现常见SQL性能问题。不过实际效果仍需结合执行计划和数据分布验证。
将库存余额与流水放在同一事务中维护，兼顾实时查询和可追溯性，思路较稳妥。对于高并发场景，还需要进一步说明锁策略、幂等和对账机制。
文章对过早分库分表和报表直连交易库的风险分析较客观。年度规划除了表结构，还应配合监控、容量评估和归档演练，才能持续验证优化效果。