订单数据主要由三张数据库表组成，主订单表对应的就是用户的一个订单，每提交一次都会生成一条主订单表的数据。在有些情况下，用户可能在一个订单中选择不同卖家的商品，而每个卖家又会按照该订单中自己提供的商品计算相关的商品优惠（如满100元减10元）以及按照不同的收货地址设置不同的物流配送，所以会出现子订单的相关概念，即一个主订单会由多个子订单组成，而真正对应到具体每个商品订单信息，则保存在订单详情表中。

如果一个电商平台的业务发展健康的话，订单数据是比较容易出现因为单个数据库表中的数据量过大而造成性能的瓶颈，所以需要对他进行数据库的拆分。此时从理论上对订单拆分是可以由两个纬度进行的，一个纬度是通过订单ID（一般为自增长ID）取模的方式，即以订单ID为分库分表键；一个是通过买家用户ID的纬度进行哈希取模，即以买家用户ID为分库分表键。

两种方案做一下对比：

1、如果是按照订单ID取模的方式，比如按1024取模，则可以保证主订单以及相关子订单，订单详情数据平均落入到后端1024个数据库表中，原则上很好地满足了数据尽可能平均拆分的原则。

2、通过采用买家ID取模的方式，比如也是按照1024取模，技术上则也能保证订单数据拆分到后端的1024个数据库表中，但这里就会出现一个业务场景中带来的问题，就是如果有些卖家是交易量非常大的，那这些卖家的订单数据量（特别是订单详情表的数据量）会比其他卖家要多处不少，也就是会出现数据不平均的现象，最终导致这些卖家的订单数据所在的数据库会相对其他数据库提前进入数据归档（为避免在线交易数据库的数据的增大带来数据库性能的问题，一般将3个月内的订单数据保存在线交易数据库中，超过3个月的订单会归档后端专门的归档数据库）。

所以从对『数据尽可能平均拆分』这条原则来看，按照订单ID取模的方式看起来更能保证订单数据的平均拆分，但我们暂时不要这么快下结论，也要根据不同的业务场景和最佳实践角度多思考不同纬度带来的优缺点。