月度归档：2026年7月 (56)
跨分片查询（上）：聚合与排序的归并代价
不带分片键的查询不是不能跑，是要付出「扫全部片、再归并」的代价——count 要加法归并，avg 要先拆 sum 与 count，全局排序要堆归并，group by 最重。把每一类聚合的归并账本算清楚，才能在「加一跳异构」和「接受归并开销」之间做对选择。
中间件之下：SQL 改写、归并与执行的流水线
一条逻辑 SQL 进来，中间件悄悄做了什么？表名换成真实表、limit 改写成重算的分页、avg 拆成 sum 加 count——然后并发打到多个分片，再把结果归并回来。看懂这条五步流水线，分片环境里九成的诡异问题都能自己定位。
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 说这不是慢，是这张表已经不配再被改了。索引膨胀、磁盘水位、备份窗口全面告急，单库的天花板不是猜出来的，是一次次撞出来的。什么时候真的需要分库分表，这篇先把决定时刻讲清楚。