支付业务订单系统分库分表支付系统中订单业务主要有四个查询维度：订单、用户、商户、运营。从查询数据库字段来看，B2B、B2C等模式：商户ID+商户订单号查询，商户ID+商户订单号是唯一约束。商户号查询，如商户后台查询、运营后台查询。系统订单号查询，由订单系统自己生成，全局唯一性约束。用户号查询，如电商业务，查询自己的订单系统订单号+用户号查询，如用户精准查询个人订单无条件查询，如运营后台查询B2B业务设计到分库核心查询业务分表字段：商户号+商户订单号查询，商户号+商户订单号为唯一约束。商户号查询，如商户后台查询、运营后台查询。系统订单号查询，由订单系统自己生成，全局唯一性约束。分库分表的一个思路：系统序号生成规则：将分库分表的数据写入生成规则，即可定位位置。商户ID规则：取商户ID的后4位作为shardkey，进行hash取模。对于B2C业务，建议对订单数据进行冗余备份，分为买家库和卖家库。数据库通过消息中间件或其他同步工具异步更新。)和卖家数据库的shardkey（截取卖家ID）包含在订单ID中，方便卖家相关业务在查询订单详情时直接到卖家数据库。综合分析如果2C和2B业务综合存在，建议拆分业务。没有必要将所有数据放在同一个业务逻辑中。订单数据有一个特殊点。随着时间的推移，大量数据会变成冷数据，使用率会下降。按创建时间划分表也是一个不错的选择。所以分库分表其实并没有统一的规划，需要根据业务进行详细的设计。比如按创建时间分表：时差，是不是要冗余查询，因为支付单的时效性，默认可以查询2天的数据。支付订单是有有效期的，比如订单过期了，所以可以设置规则，接口只能查询当天的数据。商户后台可以使用一些数据同步手段，比如渠道同步到es等。总结：实际场景具体分析，没有统一的解决方案。
