公司目前还是采用的单一数据库。订单量每天20W条数据左右，订单表按地区进行了分表，例如 重庆：CQ_Order 成都：CD_Order 北京：BJ_Order 等等以此类推。 目前还没有出现性能问题。但时间一长，单一数据库肯定会出现性能的问题。
我设想把单一数据库改造成分布式数据库的形式，按照地区对订单数据进行分库 例如
重庆的订单提交到重庆的数据库(CQ_Database)
北京的订单提交到北京的数据库(BJ_Database)
成都的订单提交到成都的数据库(CD_Database)
。。。以此类推
(只是对订单数据进行分库，其余公用数据还是存放在一个数据库中(Public_Database))
请问大神我这样的设计是否合理
还有一些关于查询的细节问题比如
如果查询订单数据需要跟公用数据库某些表进行关联查询的时候该怎么办。 垮库查询我觉得很麻烦
如果不跨库查询， 就需要把公用数据库的数据同步到每个地区数据库去。
请做过分布式数据库设计的大神谈谈经验。
------解决思路----------------------
没做过分布式，不过我胡讲一句
感觉楼主的解决方案不可行，如果真要这样，首先，数据库的拓扑结构会影响到客户端这一块，因为你客户端编程时要连接不同的数据库，一旦未来规模更大，再进行细分的时候，还要改客户端的代码。这种解决方案最好的情况是能在保证客户端不变的情况下能够动态伸缩数据库是最好。
不知道数据库集群可不可以解决这件事。没做过，意见仅供参考。
------解决思路----------------------
对历史数据进行归档 对现在的数据进行查询是没有什么性能问题的吧？
如果要分区 可以对历史表进行分区。历史表可以不按照地区分，分区可以按照时间进行分区，比较好管理。
------解决思路----------------------
分库还是分服务器？
前者不算分布式吧
------解决思路----------------------
分布式磁盘整列存储分布式数据库服务模式 统筹 联通