自带分库规则，这里的用户标识码即为用户ID的后四位，在查询的场景下，只需要订单号就可以匹配到相应的库表而无需用户ID，只取四位是希望订单号尽可能的短一些，并且评估下来四位已经足够。

可排序，因为时间戳在最前面。

当然也有一些缺点，比如长度稍长，atv，性能要比int/bigint的稍差等。

　　其他问题

事务支持：我们是将整个订单领域聚合体切分，维度一致，所以对聚合体的事务是支持的。

复杂查询：垂直切分后，就跟join说拜拜了；水平切分后，查询的条件一定要在切分的维度内，比如查询具体某个用户下的各位订单等；禁止不带切分的维度的查询，即使中间件可以支持这种查询，可以在内存中组装，但是这种需求往往不应该在在线库查询，或者可以通过其他方法转换到切分的维度来实现。

　　数据迁移

数据库拆分一般是业务发展到一定规模后的优化和重构，为了支持业务快速上线，很难一开始就分库分表，垂直拆分还好办，改改数据源就搞定了，一旦开始水平拆分，数据清洗就是个大问题，为此，我们经历了以下几个阶段。

第一阶段

数据库双写（事务成功以老模型为准），查询走老模型。

每日job数据对账（通过DW），并将差异补平。

通过job导历史数据。

第二阶段

历史数据导入完毕并且数据对账无误。

依然是数据库双写，但是事务成功与否以新模型为准，在线查询切新模型。

每日job数据对账，将差异补平。

第三阶段

老模型不再同步写入，仅当订单有终态时才会异步补上。

此阶段只有离线数据依然依赖老的模型，并且下游的依赖非常多，待DW改造完就可以完全废除老模型了。

　　简单总结

并非所有表都需要水平拆分，要看增长的类型和速度，水平拆分是大招，拆分后会增加开发的复杂度，不到万不得已不使用。

在大规模并发的业务上，尽量做到在线查询和离线查询隔离，交易查询和运营/客服查询隔离。

拆分维度的选择很重要，要尽可能在解决拆分前问题的基础上，便于开发。

数据库没你想象的那么坚强，需要保护，尽量使用简单的、良好索引的查询，这样数据库整体可控，也易于长期容量规划以及水平扩展。

最后感谢一下棒棒的DBA团队和数据库中间件团队对项目的大力协助！

　　活动彩蛋

华为软件开发云是一个智能化软件研发管理平台，

通过云服务的方式开放华为20多年积累的软件工程能力，

助力软件开发团队打造一流的软件产品。

风起云又聚，华为企业云邀你共赢未来，

3月22日，我们在华为青岛软件开发云大会见！

戳 「 阅读原文 」，即刻报名！

　　今日荐号

　　StuQ

　　InfoQ推出的IT教育平台——斯达克学院（StuQ ）为技术人提供系统实战课程学习微服务，机器学习，iOS开发最潮流技术回复“课程”获得热门课程介绍和优惠码

　　微信ID:stuq2015