1. 项目背景与核心需求拆解做了几年电商业务的数据库运维我越来越觉得库存表是系统里最让人头疼的一类数据。接手悠悠有品这个项目的时候业务已经不是简单的“单机房单库”而是多个地域同时运营、多个仓库并行发货的规模。最直观的压力来自库存检索用户搜索一个SKU页面必须马上展示“有多少现货、能不能发到当前地址、多久能到”而后台要做库存预占仓配系统要做调拨决策。所有环节都依赖同一个基础能力——在几百毫秒内查到实时且准确的库存。1.1 多地域业务给库存检索带来的实际问题多地域运营的第一个问题是库存数据天然分散。每个区域有独立仓网同一件商品在不同地域的库存数量、可售状态完全不一样甚至同一地域内还分前置仓、中心仓、退货仓。传统做法是各区域各建一套订单和库存系统但用户是流动的一个用户可能在北方下单却希望从南方的仓发货。如果只查本地库存要么超卖要么漏卖。第二个问题是数据同步带来的延迟。库存数据如果分散在多个MySQL实例里应用层需要挨个查、再合并结果。业务低峰期还能接受一旦上活动查询量大几十倍靠“多线程并发查多个库”的方案很快会遇到三个瓶颈连接数被打满、跨库合并计算速度变慢、数据一致性难以保证。我们曾经在线上出现过一次“库存显示有货但下单后缺货”的事故原因就是一个区域的Redis缓存过期了而另一个区域的数据库事务还没提交应用层把两边的数据拼在一起得出了错误结论。第三个问题是“智能检索”这个词背后的真实复杂度。它不只是按SKU查一个总数而是需要组合多个条件按地域、仓库类型、库存状态、可售后剩余时间、预售标记、是否支持极速达等筛选再根据履约成本排序。单条SQL看起来不复杂但在大分区、大表、多条件组合的场景下如果索引设计不对一次查询很容易扫几百万行延迟直接冲到秒级。1.2 毫秒级智能检索到底意味着什么标题里“库存毫秒级智能检索”中的“毫秒级”我的理解不是所有查询都必须在10毫秒内返回而是TP50能稳定在50毫秒以内、TP999尽量控制在200毫秒以内。电商场景里用户看到“库存不足”的瞬间就会流失所以详情页的库存展示、购物车预占、下单扣减这三个动作都必须足够快。“智能”则体现在两个层面。第一层是查询引擎能自动选择最优执行路径。同样的查询换一个筛选条件组合最优索引可能完全不同。靠业务代码里写死索引提示是不现实的必须依赖数据库的优化器和索引设计来“猜”出正确方案。第二层是数据结果要符合业务语义比如“可售库存”和“物理库存”不是一回事智能检索要把锁定库存、调拨中库存、在途库存都计算进去再给上层一个准确的数字。悠悠有品当时的真实场景让我意识到与其在应用层堆缓存、堆并发不如先把数据库这个底座打磨好。只有底层能扛住复杂查询上层缓存才能放心做短时间透传否则缓存一旦失效数据库立刻会被打垮。1.3 技术选型前的几个候选方案在决定用PolarDB之前我们实际对比过几条路线。第一条是继续用自建MySQL Plus业务层缓存。优点是团队熟悉缺点是跨地域容灾、只读扩展、复杂查询并行化都需要自己造轮子尤其是大促前扩容机房准备周期至少两周响应太慢。第二条是引入独立的搜索引擎或分析型数据库来承接库存检索。思路是把库存数据异步同步到Elasticsearch或列式仓库查询走搜索集群数据库只负责事务写入。这个方案的查询能力强但带来了新的问题数据链路变长同步延迟不可控而且库存场景要求强一致搜索引擎的最终一致性在“下单前校验库存”这个环节很难让业务放心。我们尝试过小流量验证发现同步组件一旦抖动就会出现“搜索显示有货、下单时无货”的尴尬情况必须额外做对账补偿成本很高。第三条是使用云原生数据库PolarDB把多地域的业务流量直接打在同一个数据库体系上。当时吸引我的点有三个第一它兼容MySQL应用层改动很小第二存储计算分离架构让只读节点可以随时扩展多地域可以部署只读实例就近读取第三它的并行查询和列存索引正好能处理我们那种“大表多条件聚合”的检索场景。结合悠悠有品本身已经部署在云环境的现状我们最终选择了PolarDB作为库存检索底座。2. PolarDB的多地域部署与关键能力解析确定选型之后团队内部最关心的问题变成了PolarDB到底靠什么支撑多地域业务以及它和传统MySQL主从架构的本质区别在哪里。这个问题如果不理清楚后续的压测和调优都会没有方向。2.1 存储计算分离和一写多读带来的架构变化传统MySQL的主从复制本质上是把Binlog从主库传到从库再由从库回放。数据量小的时候问题不大但库存表这种写入频繁、热点集中的场景从库回放往往会成为瓶颈。PolarDB采用了存储计算分离的架构计算节点和存储节点独立扩展一写多读。它最大的变化是多个只读计算节点共享同一份分布式存储上的数据主节点写入的数据只读节点几乎实时可见。这个架构对库存检索有直接帮助。悠悠有品的业务分为两类流量一类是下单扣减库存必须走主节点保证强一致另一类是页面查询和智能检索允许走只读节点读取最新数据。放在以前我们需要给每个地域单独部署一套MySQL从库再用中间件做读写分离。现在只需要在主地域部署一个写节点在各个业务地域部署只读计算节点所有只读节点读到的都是同一份存储数据。对应用来说连接不同的只读节点就行不需要再关心复制链路是否跟得上。我实际使用中最明显的感受是库存表的只读节点不再需要担心“回放延迟导致数据偏旧”。因为只读节点不需要通过Binlog回放而是直接从共享存储读取最新版本的数据延迟被压缩到了极低水平。这一点对库存查询非常关键我们可以在详情页放心地让查询流量走只读节点而不需要额外加一层缓存来掩盖同步延迟。2.2 多地域数据同步与就近读取多地域业务还涉及一个“就近读取”的问题。用户的访问可能来自不同地域如果所有查询都回到中心数据库网络时延会成为首要瓶颈。PolarDB解决这个问题的方式是在各地域部署只读节点并通过全局数据库网络把主地域的数据同步过去。我们当时的部署形态是中心地域放一个主集群承担所有写入另外两个业务地域各放一个只读集群承担本地读流量。业务接入层会根据用户IP归属路由到最近地域的只读集群。数据库内部的同步机制保证了跨地域的只读数据不会严重滞后。实测下来在业务低峰期跨地域数据延迟基本可以稳定在几十毫秒内对库存展示类查询来说完全够用。这里要说一个容易被忽略的点多地域部署不是“创建几个只读实例”就结束了还需要考虑地域间的网络链路质量。我们踩过坑最初只追求节点数量没有把只读集群和主集群之间的网络延迟纳入监控结果某地域的库存查询偶尔出现一个几十毫秒的连接等待。后来在数据库参数里调整了tcp相关的超时阈值并在应用层增加了地域路由的兜底逻辑问题才解决。2.3 为什么PolarDB适合库存检索场景库存检索场景最核心的诉求是“高并发 多条件组合 强一致”。PolarDB的并行查询能力在上线前我们做了专项测试一条原本需要扫描上千万行的库存汇总SQL在开启并行查询后执行时间从1.8秒降到了200毫秒以内。原因是它能将一条查询拆成多个子任务在多个CPU核心上并行执行再把结果合并返回。这种能力对那种“按地域查多个SKU库存总和”的批量检索特别有效。另外PolarDB的列存索引也帮了大忙。库存查询经常涉及大量行但只取少数列比如“查所有仓的可售总量”传统行存索引需要逐行读取全部字段。列存索引只读取需要的列大大减少了I/O。我们把库存表的明细数据同时维护一份列存索引专门服务后台的运营类和数据分析类查询实测在数据量增长3倍后复杂条件组合查询的耗时依然能维持在300毫秒以内。对于强一致性问题PolarDB的主节点写入和只读节点读取之间使用原生复制协议而不是依赖应用层双写或消息队列。这避免了“缓存和数据库数据不一致”的经典难题。悠悠有品在实际运营中遇到的“有库存却不能下单”的问题在切换后基本消失因为查询和扣减最终都能落到同一个数据库内核的数据视图上。3. 库存毫秒级智能检索的数据模型与索引设计生产环境里数据库选型只是第一步真正决定检索快慢的是表结构和索引设计是否贴合业务。这个部分我们反复调了三轮核心思路可以总结成一句话把“智能”尽量下沉到数据库里而不是让应用层做大量预计算。3.1 库存表结构与分区策略库存数据有一个特点单条数据量不大但行数巨大而且访问有明显的分区特征——用户只会关注某个地域、某几个SKU的库存不会一次性查询全平台所有商品。因此库存表必须做分区。我们最终采用的表结构类似下面这样CREATE TABLE inventory_sku ( region_id varchar(16) NOT NULL, warehouse_id bigint NOT NULL, sku_id bigint NOT NULL, total_qty int NOT NULL, locked_qty int NOT NULL, available_qty int GENERATED ALWAYS AS (total_qty - locked_qty) STORED, stock_status tinyint NOT NULL, extra_attrs json DEFAULT NULL, last_modified_time datetime NOT NULL, PRIMARY KEY (region_id, warehouse_id, sku_id), KEY idx_sku_region (sku_id, region_id), KEY idx_status_region (stock_status, region_id, available_qty) ) PARTITION BY HASH(region_id) PARTITIONS 24;这里有几个设计点值得展开说。第一主键以region_id开头保证同一个地域的数据尽量落在同一个分区内查询时能直接做分区裁剪。第二用生成列available_qty代替了“应用层先查两个字段再相减”的做法让数据库在索引里直接参与条件过滤。第三extra_attrs用JSON类型存储商品的各类扩展属性例如“是否支持次日达”“是否支持门店自提”这样可以避免频繁加列。分区数我们选择了24而不是简单等于地域数。原因是单地域内的数据量也会增长分区数太多会导致小文件过多、元数据管理复杂太少则无法发挥分区裁剪的作用。24这个数字是压测后选出来的兼顾了并发分散和资源利用。3.2 智能检索的查询条件与索引设计业务侧最常见的查询是用户选择一个收货地域然后系统找出所有满足条件的SKU并按可售库存数量排序。对应的SQL原型是SELECT sku_id, SUM(available_qty) AS total_available FROM inventory_sku WHERE region_id ? AND stock_status 1 AND available_qty 0 AND JSON_CONTAINS(extra_attrs, {is_next_day: true}) GROUP BY sku_id ORDER BY total_available DESC LIMIT 20;这条SQL看起来不难但如果没有合适的索引数据库需要扫描整个region分区再对每一行做JSON判断和聚合。我们实际遇到的问题是region_id已经走了分区裁剪但stock_status和available_qty的过滤度不够好导致扫描行数还是偏多。解决办法是建立了一个二级索引idx_status_regionstock_status, region_id, available_qty。这个索引的列顺序是有讲究的等值条件stock_status放最前面第二个用region_id继续过滤最后一个才是范围过滤available_qty 0。优化器能通过这个索引快速定位到少量行再回表读取extra_attrs做JSON过滤。优化前后对比很明显一条平均查询的扫描行数从120万行降到了3000行耗时从800毫秒降到了40毫秒。对于JSON字段的过滤我们也试验过在列存索引上建立虚拟列但后来发现JSON_CONTAINS在数据量没有爆炸性增长时性能已经够用没必要引入额外复杂结构。真正需要关心的是不要让JSON过滤单独打头阵一定要先用普通列的高选择性条件把数据范围缩得足够小。3.3 SQL调优与执行计划分析索引建好之后还必须在真实流量下持续观察执行计划。PolarDB可以使用EXPLAIN查看详细计划我们每次发布前都会对核心SQL做一次执行计划审查。常见的坑有两个一个是优化器因为数据分布变化而放弃最优索引另一个是分区裁剪失效导致全分区扫描。针对第一个问题我们会在每周的例行维护里更新统计信息并给关键查询使用固定的索引提示。针对第二个问题我们允许业务层在SQL里显式带上region_id不允许不带地域条件的全表检索。业务一开始嫌麻烦后来发现不带地域条件的查询实在无法接受就主动配合改了。参数调优方面对库存检索比较关键的是并行度和缓冲区大小。我们开启并行查询后将并行度设为CPU核数的一半避免多个复杂查询同时并行时把CPU打满。缓冲池参数设置的调整让热点SKU的索引页能长期驻留内存实测命中率稳定在95%以上。这套组合拳下来线上的大促峰值期间核心库存检索接口TP99控制在180毫秒以内达到了业务提出的“毫秒级智能检索”目标。4. 从迁移到上线的实操过程记录再好的架构最终也要落到一次次具体的迁移和配置上。我们把原来的自建MySQL库存库切换为PolarDB时前后花了两周时间其中踩过的坑不少。这一部分我把操作流程和当时的调整记录整理出来给需要做类似迁移的同学一个参考。4.1 自建数据库迁移到PolarDB的主要步骤第一步是兼容性检查。我们把所有库存相关的建表语句、查询SQL和存储过程在PolarDB的测试实例上跑了一遍重点看自增主键、JSON函数、分区表语法是否兼容。实测下来百分之九十五以上的语句无需改动只有少量自定义的存储过程因为权限和函数差异需要重写。第二步是数据迁移。我们用的是云数据传输服务先做全量迁移再做增量同步。全量迁移的过程很快核心卡点反而是对源库的读压力。为了避免影响线上业务我们把迁移任务的并发降到了一半选择凌晨低峰期执行。增量同步启动后业务可以逐步读取PolarDB只读节点观察数据是否一致。第三步是新老库并行验证。我们让业务流量先按1%的比例切到PolarDB对比新老库返回的库存数字和响应时间。这个过程发现了不少小问题比如某个查询在MySQL里能走索引在PolarDB里因为统计信息不新导致走了全表扫描执行时间差了十倍。解决办法就是重新收集统计信息并调整查询中的索引提示。并行验证跑了两天确认无误后才在某个周一凌晨完成全量切换。4.2 多地域集群部署与读写分离配置切换完成后紧接着就是多地域部署。我们在中心地域保留主集群另外两个业务地域各建了一个只读集群并在网络层面打通了专线。数据库层需要做的配置包括开启跨地域复制、设置只读节点的一致性级别、配置连接地址。应用层的读写分离则比较简单。库存扣减和订单创建走中心主集群库存展示和智能检索走本地只读集群。我们在应用配置里维护了一个地域路由映射表用户带上的地域参数会直接决定走哪个连接池。这里有个经验只读集群的地址一定要做“多活”不能依赖单个可用区的域名解析。我们曾经因为某个可用区的网络抖动导致该地域所有库存查询超时后来改成了多可用区地址后单点故障的影响明显减小。4.3 压测与参数调优实录上线前我们做了两轮压测。第一轮是单地域压测模拟1000个并发用户同时查询库存详情。刚开始的结果不太理想P99达到了600多毫秒排查发现是连接池默认最大连接数太小请求排队严重。调整连接池后P99降到了220毫秒。第二轮是多地域混合压测加入了跨地域复制和只读节点的因素。这轮暴露出同步延迟的稀释问题某个地域的只读集群复制延迟超过了500毫秒导致该地域查询到的库存比主集群落后一截。我们检查后发现是跨地域的回放链路带宽不足在高峰期出现拥塞。解决方法是加大对地域间同步链路的带宽同时在业务上允许库存展示容忍300毫秒以内的“近实时延迟”但下单前校验仍然强制走主节点。压测最终数据如下场景并发数TP50TP99错误率单地域库存详情查询80018ms95ms0.00%多地域智能检索60042ms180ms0.00%库存扣减主节点50025ms130ms0.00%这个结果满足了业务方最初的要求。更重要的是我们通过压测摸清了系统的容量水位后续大促扩容时直接按这个比例预留资源心里有数多了。5. 常见问题与排查技巧实录整个项目上线稳定运行之后日常维护中依然会遇到各种“灵异事件”。这里把最有代表性的几个问题以及排查思路写下来权当是给同行的一份避坑清单。5.1 慢查询与索引失效怎么办最典型的场景是某天突然收到慢查询告警一条原本执行几十毫秒的库存汇总SQL突然变成了1秒多。第一时间别急着改SQL先看执行计划。我们发现大部分情况是统计信息过期优化器低估了某些条件的过滤性选错了索引。解决方法是执行ANALYZE TABLE更新统计信息同时对核心查询做固定索引提示。另一个原因是隐式类型转换导致的索引失效。比如region_id字段是varchar但应用传入的是整型数字MySQL的隐式转换会让索引失效。排查这类问题有个技巧对比慢查询日志和EXPLAIN中的possible_keys如果显示可能能用索引但实际没走多半就是类型不匹配或查询条件写得太复杂。5.2 跨地域同步延迟怎么监控和消除跨地域复制的延迟是运行中比较常见的问题。我们监控的指标是复制延迟时间正常情况下应该保持在200毫秒内。如果发现某地域持续超过1秒大概率是网络链路问题或大事务阻塞。曾经有一次运营后台执行了一个批量的库存调整事务一次性更新了几百万行的数据导致跨地域同步延迟瞬间飙升。那次之后我们限制了后台批量更新事务的行数把大事务拆成小批次并配置了只能路由到主地域的重试机制。现在再遇到延迟升高基本能快速定位到是哪类SQL造成的影响。5.3 缓存一致性踩坑记录一开始为了追求更快我们在PolarDB前面加了一层Redis缓存缓存的是“某SKU在某地域的总可售库存”。后来发现一个隐蔽问题库存扣减成功但缓存没有及时失效用户看到的数字是旧的。原因是我们只设置了过期时间没有在事务成功后主动删除缓存而业务上事务成功和缓存删除之间隔了一个消息异步环节一旦消息处理失败缓存就会长期脏读。最后的解决方式很简单库存变更事务成功后直接在主线程里删除对应缓存不做异步删除失败则捕获异常并上报监控宁可让缓存穿透到数据库也不能让用户读到错误库存。经过这次调整缓存一致性告警基本归零。5.4 大促期间热点库存怎么优化大促期间一些爆款SKU的访问量会放大几十倍可能集中在某一个地域和某几个仓库上。这会导致底层数据库的某个分区或索引页成为热点。我们采用的方案有三个一是对热点SKU的库存查询开启结果缓存短时间内的相同查询直接返回缓存数据二是在数据库层对热点读做限流降级保证非热点查询不被拖垮三是把库存扣减的幂等校验尽量前置到业务层用分布式锁控制超卖减少无效的数据库查询。5.5 日常巡检与告警配置建议最后建议维护库存类数据库的同学一定要做好四类告警慢查询数量、复制延迟、活跃连接数、Buffer Pool命中率。其中Buffer Pool命中率尤其重要如果明显下降往往意味着数据量增长超过了内存规划需要扩容或者优化索引。我们的巡检脚本每周跑一次会检查执行计划变化、表碎片率、分区大小分布发现问题提前处理而不是等线上出故障再补救。6. 一点个人体会悠悠有品这个项目让我对“选型”这件事有了更深的体会。以前总觉得分布式中间件越多越高级实际上对于库存这种强一致、高并发、多条件检索的场景一个具备存储计算分离能力、兼容MySQL、自带并行查询的数据库往往比“数据库加搜索引擎加缓存再加MQ”的一大套组合更稳、更好维护。如果让我重新再做一遍我会更早地把多地域同步延迟的监控做细而不是等到压测时才暴露。延期排期总比线上故障要好。这篇内容里提到的表结构、SQL和调优参数都是我们实实在在调试过的方案。每个业务的数据分布和访问特征都不一样直接照搬不一定最优但整体思路应该可以复用先让数据库能撑住核心查询再用最小化缓存方案提升速度最后用完善的监控守住稳定性。