需求背景
项目当前架构：当前架构数据共享仅支持在跨机构之间，如果集团内部如果需要不同子公司做数据共享，则需要子公司分别单独部署该系统。
新需求：实际场景中，集团可能统一部署该服务，不希望每个子公司单独部署和运维，子公司更多的是是使用者的角色。 因此既要满足集团之间数据共享（一个集团部署一个项目），又要满足集团内部子公司之间数据共享（还是集团只部署一个项目，子公司共用该平台，但要做到数据隔离），还要满足公司内部数据共享。
数据隔离方案考究
究竟是采用分库还是分表，在参考了诸多前辈的文章后，对我所做的业务进行了一定程度的分析，分析方面主要为两个方向：一是自身业务压力的承载能力和业务流量特点；二是所采用的数据库和服务器本身的承载能力
自身业务现状
数据库现状
现有模式下数据库表数量：70个（项目启动后固定生成的数据表）+ n（用户可自由导入数据生成的数据表）
预估一般子机构数量：200内
机构及子机构存储的数据总量：由机构及子机构决定（未知：(70+n)*200）
业务其他现状
- 无峰谷流量波动，较为平稳
- 数据库操作读多写少
- 没有使用缓存中间件技术 - 暂不需要
mysql数据库现状
最大连接数：Mysql5.5～5.7：默认的最大连接数都是151，上限为：100000 ；Mysql5.0版本：默认的最大连接数为100，上限为16384
表数量：一般最多20亿个表，InnoDB允许多达 40 亿张表。（底层文件系统可能对代表表的文件数量有限制）
数据库的数量限制：Mysql对数据库的数量没有限制。底层文件系统可能对目录的数量有限制。
有一组数据可以参考：库物理文件大小<100G，表<100，字段<200，单表记录数<500W
此范围内的写入读取性能是比较好的
分库还是分表
| 分析点 | 分表 | 分库 | 分库还是分表 |
| 数据库数量 | 所有机构共用一个数据库 | 机构数量决定 预估200内 | 分库较好（单库能够支撑的并发量是有限的；业务量剧增，单库数据量越来越大，给存储造成巨大压力） |
| 单库表数量 | (70+n)*200 > 1.4w | 70+n | 分库较好（分表情况下单库的表数量较多，且表数量也不可估量；SQL 操作会变慢） |
| 单库数据量 | 集团及子机构的数据量总和 | 具体单个机构的数据量 | 分库（子机构数据总量不可估量） |
| 连接数 | 机构及子机构连接数总和 | 最大为机构及子机构连接数总和 | 分库（分表情况下，若每个机构同时取得100个连接，则100*200>16384，易出现数据库连接数过多问题） |
| 读写压力 | 集中在一个库 | 分散在多个库，减轻压力 | 分库（分表情况下增加了数据库读写压力） |
水平或垂直分库分表利弊分析
最终结论
采用水平分库方案
