一杯咖啡的时间，聊聊技术与成长
ShardingSphere-JDBC 接入实战：分片配置跑起来
说了六篇原理，该让代码跑起来了。引入 shardingsphere-jdbc 依赖、声明逻辑表与真实表节点、写好分片算法——三十行配置，订单表按 user_id 取模的 8 库 32 表就转起来了。配置里的每一个字段，都对应着前几篇的一个决策。
路由：从代码 if-else 到中间件
分片键定了，路由规则算得出数据在哪儿——但这段逻辑放在哪儿执行，决定了系统的可维护性。硬编码灵活在手里、死在未来；代理层集中但多一跳；SDK 内嵌在进程里，性能与治理兼得。三种落法对应系统规模的三段演进。
分片键：一次选择，终身锁死
切多细、用什么刀法都能改，唯独分片键定了就改不动——所有查询都必须带上它，不带就全分片扫荡。订单系统选 buyer_id 还是 seller_id 还是订单号？基因法给出第三条路：把两个维度都埋进 ID 里。这个决策的代价，要用很多年偿还。
水平拆分的三种刀法：Range、Hash 与查表
两亿行订单往哪儿切？Range 按时间切，扩容顺滑但热点扎堆；Hash 按键取模，均匀但扩容要大规模搬数据；查表法最灵活，代价是多一层维护。三种刀法没有绝对优劣，只有与业务增长曲线的匹配度——选错刀法，扩容那天会还回来的。
垂直拆分：按业务切库，按冷热切字段
水平拆分之前的第一次动刀往往是垂直的：把混在一个库里的订单、商品、用户按业务边界切开，把大字段和冷字段从主表里请出去。垂直拆成本低、边界清晰，但它治不了单业务的数据量——真正的天花板要靠水平拆来顶。
拆之前的三招：把单库性能先榨干
急着拆表之前，先问一句：索引建对了吗？冷数据归档了吗？读流量分出去了吗？归档瘦身是最立竿见影的一刀，读写分离扛住读增长，索引与 SQL 治理解决慢的根源——三招打完还顶不住，才是分库分表真正的入场券。
单表两亿行：一次改了八小时的 DDL，逼出了分库分表
给一张两亿行的订单表加字段，gh-ost 跑了八小时还差三个槽——dba 说这不是慢，是这张表已经不配再被改了。索引膨胀、磁盘水位、备份窗口全面告急，单库的天花板不是猜出来的，是一次次撞出来的。什么时候真的需要分库分表，这篇先把决定时刻讲清楚。
收官：稳定性体系全景图
二十篇走到收官。从一次爆单雪崩出发，装了限流、熔断、降级、隔离、超时五道闸，配了重试纪律、自适应、全链路压测三套方法论，最后归拢成一张全景图：流量进来怎么挡、故障起来怎么断、用户侧怎么保、事后怎么复盘。稳定性没有银弹，只有纵深。
事故集锦：十个真实故障复盘
十个真实事故对应本系列的十件武器：没设超时的等待、恢复瞬间的重试、共用的线程池、混部的报表、低峰误跳闸、反复横跳的半开、陈年缓存兜底、挂掉的降级开关、打爆分片的热 key，以及一次因演练过而毫发无损的故障。看别人的事故，长自己的记性。