多租户动态多数据源系列
1、基于springboot+jpa 实现多租户动态切换多数据源 - 数据隔离方案选择分库还是分表
2、基于springboot+jpa 实现多租户动态切换多数据源 - 基于dynamic-datasource实现多租户动态切换数据源
3、基于springboot+jpa 实现多租户动态切换多数据源 - 使用Flyway实现多数据源数据库脚本管理和迭代更新

需求背景

项目当前架构：当前架构数据共享仅支持在跨机构之间，如果集团内部如果需要不同子公司做数据共享，则需要子公司分别单独部署该系统。

新需求：实际场景中，集团可能统一部署该服务，不希望每个子公司单独部署和运维，子公司更多的是是使用者的角色。 因此既要满足集团之间数据共享（一个集团部署一个项目），又要满足集团内部子公司之间数据共享（还是集团只部署一个项目，子公司共用该平台，但要做到数据隔离），还要满足公司内部数据共享。

数据隔离方案考究

究竟是采用分库还是分表，在参考了诸多前辈的文章后，对我所做的业务进行了一定程度的分析，分析方面主要为两个方向：一是自身业务压力的承载能力和业务流量特点；二是所采用的数据库和服务器本身的承载能力

自身业务现状

数据库现状

现有模式下数据库表数量：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，易出现数据库连接数过多问题）
读写压力	集中在一个库	分散在多个库，减轻压力	分库（分表情况下增加了数据库读写压力）

水平或垂直分库分表利弊分析

水平or垂直区分	垂直分库	垂直分表	水平分库	水平分表
判断依据	根据业务耦合性，将关联度低的不同表存储在不同的数据库，如按业务分类进行独立划分	基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中	当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平切分了	根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果
优点	1. 解决业务系统层面的耦合，业务清晰；2. 与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等；3. 高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈	1. 解决业务系统层面的耦合，业务清晰；2. 与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等；3. 高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈	1. 不存在单库数据量过大、高并发的性能瓶颈，提升了系统稳定性和负载能力； 2. 应用端改造较小，不需要拆分业务模块	应用端改造较小，不需要拆分业务模块
缺点	1. 部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度；2. 分布式事务处理复杂；3. 依然存在单表数据量过大的问题（需要水平切分）	1. 部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度；2. 分布式事务处理复杂；3. 依然存在单表数据量过大的问题（需要水平切分）	1. 跨分片的事务一致性难以保证；2. 跨库的join关联查询性能较差；3. 数据多次扩展难度和维护量极大	1. 数据多次扩展难度和维护量极大；2. 库内分表只解决了单一表数据量过大的问题，但没有将表分布到不同机器的库上，因此对于减轻MySQL数据库的压力来说，帮助不是很大，大家还是竞争同一个物理机的CPU、内存、网络IO

最终结论

采用水平分库方案

参考

• MySQL 5.7 参考手册
• MySQL分库分表方案
• “分库分表" ？选型和流程要慎重，否则会失控
• MySQL：互联网公司常用分库分表方案汇总！
• 水平分库分表的关键步骤以及可能遇到的问题
• 有关分库分表 ShardingSphere-JDBC，这是我见过整理的最全的笔记了