一杯咖啡的时间，聊聊技术与成长
水平拆分的三种刀法：Range、Hash 与查表
两亿行订单往哪儿切？Range 按时间切，扩容顺滑但热点扎堆；Hash 按键取模，均匀但扩容要大规模搬数据；查表法最灵活，代价是多一层维护。三种刀法没有绝对优劣，只有与业务增长曲线的匹配度——选错刀法，扩容那天会还回来的。
垂直拆分：按业务切库，按冷热切字段
水平拆分之前的第一次动刀往往是垂直的：把混在一个库里的订单、商品、用户按业务边界切开，把大字段和冷字段从主表里请出去。垂直拆成本低、边界清晰，但它治不了单业务的数据量——真正的天花板要靠水平拆来顶。
拆之前的三招：把单库性能先榨干
急着拆表之前，先问一句：索引建对了吗？冷数据归档了吗？读流量分出去了吗？归档瘦身是最立竿见影的一刀，读写分离扛住读增长，索引与 SQL 治理解决慢的根源——三招打完还顶不住，才是分库分表真正的入场券。
单表两亿行：一次改了八小时的 DDL，逼出了分库分表
给一张两亿行的订单表加字段，gh-ost 跑了八小时还差三个槽——dba 说这不是慢，是这张表已经不配再被改了。索引膨胀、磁盘水位、备份窗口全面告急，单库的天花板不是猜出来的，是一次次撞出来的。什么时候真的需要分库分表，这篇先把决定时刻讲清楚。
收官：稳定性体系全景图
二十篇走到收官。从一次爆单雪崩出发，装了限流、熔断、降级、隔离、超时五道闸，配了重试纪律、自适应、全链路压测三套方法论，最后归拢成一张全景图：流量进来怎么挡、故障起来怎么断、用户侧怎么保、事后怎么复盘。稳定性没有银弹，只有纵深。
事故集锦：十个真实故障复盘
十个真实事故对应本系列的十件武器：没设超时的等待、恢复瞬间的重试、共用的线程池、混部的报表、低峰误跳闸、反复横跳的半开、陈年缓存兜底、挂掉的降级开关、打爆分片的热 key，以及一次因演练过而毫发无损的故障。看别人的事故，长自己的记性。
全链路压测：洪水来之前先演一遍
保护机制装了一堆，能不能扛住大促，只有洪水自己知道。全链路压测把真实流量按比例回放进生产环境，压出容量上限、压出最先垮的层、压出没演练过的预案——但流量标记、影子表、安全红线，一个都省不得。
自适应保护：让系统自己拿主意
静态阈值是一张拍出来的考卷——流量涨了偏紧，扩容了偏松。自适应保护让系统按实时指标自己调阈值：TCP BBR 的测量思想、gRPC 的重试预算、Sentinel 的系统自适应规则，是同一个心法——不猜测容量，直接测量容量，用刚测得的数字约束现在的流量。
重试风暴：好心如何办坏事
下游恢复的瞬间最危险：积压请求、层层重试、用户刷新全在门口排队，门一开洪水同时灌进来。重试是善良，无节制的重试是 DDoS——三重放大会把 10 倍流量打成上百倍。指数退避、随机抖动、重试预算、熔断联动，纪律一个都不能少。