学海无涯，心存高远。
通过字段隔离
这个实现是最简单的，但隔离性较低，后期租户变多、数据量变大可能会引发性能问题。
实现
需要隔离的表都加上“tenant_id”字段，查询时带上“tenant_id”条件。
技术预演时使用了 mybatis-plus 的多租户解决方案。
-
优点是可以自动帮忙拼接“tenant_id”条件。
-
缺点是不够灵活，它有两个维度来判断是否需要自动拼接“tenant_id”条件：tableName、sql。
通过分表隔离
隔离性有一定的改善，租户过多，每个租户又没有太多数据时会造成资源浪费。
实现
每个租户建立新的表，比如有 A、B、C 三个租户，数据库中 account 表为：a_account、b_account、c_account。
使用了 mycat 进行了技术预演，分表使用了 tenant_id + 表名的方式。一轮测试下来就乱套了，表太多，导致在数据库里查个数据都很费劲。
通过 Schema 隔离
同一个数据库里面有多个 Schema，每个 Schema 代表了一个租户。未做技术预演。
通过分库隔离
隔离性最好，数据汇总、互通比较麻烦，成本过高。
实现
mybatis-plus 正好有一套动态数据源的方案： dynamic-datasource-spring-boot-starter
最终选定方案
从灵活性、成本、效率多方面考虑最终选择了：字段隔离+分表隔离+分库隔离组合方案。
字段隔离方案使用在非核心业务数据、数据量不大、需要统计汇总的地方。
分表隔离方案使用在核心业务数据，防止误操作。
分库隔离方案作为后期付费租户的场景，数据更加安全。