背景：4.x 到 5.x 的跨代升级 八月底我们把分库分表中间件从 ShardingSphere 4.1 升到 5.3。4.x 用的还是旧的 sharding-jdbc 单库形态，配置散在 Spring 的 xxx.yaml 里；5.x 统一成了 shardingsphere-jdbc，配置模型完全
分库分表后，运营要查"跨商家跨库的订单" 我们订单库按 user_id 哈希分了 16 个库、每库 64 张表。单用户的订单查询很顺，因为都在同一个分片。直到运营提了个需求："给我看最近 30 天、金额大于 5000、状态是退款中的所有订单"——这个查询跨了所有库所有表，没有分片键可路由。组员在周会
8200 万行数据，怎么搬到 32 个分片里去 接上一篇。分片规则定好了、ShardingSphere 配好了，接下来的问题是：老库里那 8200 万行数据怎么搬过去，而且不能停服。 这篇文章写的是迁移本身，跟分片设计是两件事，但难度可能更大。 先算停机方案要多久 最省事的做法是挂维护页，导出导入。
8200 万行的订单表，加个索引要 6 小时 2021 年 2 月，我们的 t_order 表数据量到了 8200 万行，物理大小 68 GB（含索引）。 mysql> SELECT table_name, table_rows, -> ROUND(data_length/1024/10
DBA 丢给我一张容量曲线图 2 月底，DBA 在周会上放了张图：订单主库 t_order 已经 4200 万行，数据文件 38G，加上索引一共 51G，按每月 380 万行的增速，年底到 8000 万行，明年年中破亿。他的结论是"该考虑分库分表了"。 主管把这个评估任务派给了我。说实话我当时有点虚
