拆完之后，治理开始
系列的工程主线到这里基本走完：拆分、路由、查询、事务、主键、扩容、迁移、DDL、归档。本篇讲最后一个工程话题，也是唯一一个「没有终点」的话题——治理。分库分表把一个数据库变成几十个，运维对象翻了数十倍，过去「看一下库的整体水位」的动作，现在变成了「看几十个库的水位分布」。治理的核心就三件事：水位看得见、倾斜治得了、容量算得准。
水位：把每片都变透明
治理的第一步是把分片级别的指标看板建起来，逐分片采集四类数据：容量——磁盘水位、行数、增长率；性能——QPS、RT、慢查询数量；资源——CPU、内存、Buffer Pool 命中率、连接数；延迟——主从延迟、双写同步延迟。关键是按分片切片展示加全局排序：一眼看出「哪片最热、哪片最满」，而不是只看平均值——平均值是分片系统的谎言，它把倾斜藏得严严实实。告警阈值按「分片最差值」设，不是按均值设。
倾斜：不均匀的三种来源
明明取模分片，为什么有的片胖有的片瘦？倾斜三个来源，对策各异。自然波动——Hash 分片也会有大数定律之外的随机偏差，偏差在正负两成内属正常，不管；业务热点——某个超大商户、某个爆款用户的写读集中在一个分片，这是设计期没防住的（分片键的取值分布没摸清），短期用查表法定向路由到独立分片（第 4 篇的混用刀法），长期看要不要为它单独立「专属租户」架构；分片键缺陷——键的哈希分布本身不均（比如键值带规律性前缀），这要改分片算法，代价直逼一次全量迁移，靠预分片槽位重映射来消化（第 13 篇的价值在这里兑现）。
容量规划：按三年算，留余量
分片数的规划公式不复杂，难在参数要诚实：目标分片数 = 三年后的总行数 ÷ 单表理想行数（千万级），再向上取成 2 的幂（为翻倍扩容留路）。参数里最容易骗自己的是增长率——用过去一年的真实增速外推，别拍脑袋。算出来是 40 就上 64 片，算出来是 500 就认真考虑 1024 槽预分片。宁多勿少：分片多了的代价是运维复杂度线性涨，分片少了的代价是一次大迁移——后者的痛远大于前者。水位到了七成就要启动扩容评估（老规矩：maxmemory 七成的同款哲学），别等九成才动。
治理例会与自动化
把治理做成机制而不是口号：月度水位盘查——逐分片过一遍容量与增速，超阈值的进扩容评估；季度倾斜审计——行数 Top 与 QPS Top 的分片各拉出来归因；自动化兜底——水位、倾斜、慢查询的采集入监控平台，阈值触发自动工单。治理的成熟度标志不是「问题为零」，是「问题从发现到处理有固定的流水线」。
工程篇章全部讲完。按系列惯例，接下来是踩坑实录——七个真实形态的分库分表事故，看看上面这些机制是怎么在实战里被绕过的。
评论 (0)