mysql 多物理机_分布式数据库的物理库是否分得越多越好？

显然不是越多越好，也不是越少越好。

分布式数据库也分两种oltp和olap。olap的数据库或数据仓库写的比较少，读的比较多，一般情况下数据量也远远大于oltp数据库。这儿我假定你用的是olap数据仓库。

在olap数据仓库的情境下，大部分是数据分析，分布式事务的影响已经很小。物理库太多，或者说每个库太小，带来的主要负面影响包括磁盘IO的性能下降，网络延迟的增加，以及任务调度的开销增大。

(1)磁盘IO性能下降。从磁盘上读1K的数据和读1M的数据，响应时间上基本上没什么区别。所以分库太小导致IO效率不高。

(2)分库太多，一个SQL查询可能会分成很多个子查询(对应不同的分库)，然后再把结果汇总到一台机器上。每个子查询都需要通过网络发送到指定的机器上去执行，并传回数据。太多的子查询会增加网络延迟。

(3)任务调度开销增大。理由同(2)。每一个子任务都要进入队列，有资源管理中心统一调度执行。只要有一个子任务没有完成，就不能返回给客户。

另外数据库系统根据采用的技术不同，对物理分库的支持个数也不一样。传统的数仓和NoSQL一般采用sharding的技术，有一个主节点来统一管理分库(分区)，所有的客户端访问都要经过这个主节点，所以这个主节点会成为瓶颈，不能支持太多的节点(当然也会影响分库的个数)。

另外一些数据库引入分布式文件系统，由分布式文件系统来管理分库，工作节点往往都是点对点的架构，这样的系统一般能支持更多的分库。

我司推出的分布式时序数据库DolphinDB, 采用第二种技术，可以支持上百万个分库。一般情况下，数据量大的时候可以采用多字段的组合分区。时间(譬如按天，周，月等分区)是一个分库维度。在一个时间单位内，数据量还是很大，可以继续按照业务字段分库(譬如金融投资的中的股票代码，物联网中的设备)。下文是DolphinDB的分布式数据库分区教程，供你参考。