这几年，各行各业的SaaS互联网系统应用比较广泛。2B应用的SaaS系统，基本上有如下特点：
- 用户数不一定多，并发性不高（相比于C端产品）
- 数据量可能会大
- 个性业务需求多，配置灵活
在数据库（Mysql）设计之初，有2个坑比较容易踩到，将会给整个系统带来麻烦，尤其后期的扩展和优化方面。
1.各个表没有加company_id
各个表很有必要进行反范式设计，都统一加上company_id，如：在电商订单处理ERP系统中，给订单商品表也加上company_id
所有表加上company_id的好处：
- 所有数据都通过company_id进行逻辑分离，相对独立
- 安全性提升：访问任何数据，都可以通过严格匹配访问者company_id和访问数据的company_id，使得任何人再怎么瞎搞，也基本只能搞乱本公司的数据，很难去访问到其它公司的数据
- 索引：自己建的所有二级索引，第一左侧索引都可以为company_id，再怎么差的情况，也不会进行全表扫描，性能下限高
- 后期提升性能：可以按company_id进行分区，这样本公司的数据写在一起，每个page里面的数据都是本公司的，从磁盘加载数据的命中率更高，能大大减少磁盘io
2.垂直分表原则不合理
2B端的SaaS系统由于业务复杂，各类个性化需求高，这样各个对象的属性可能就会更多（比如: 订单主对象可能包括卖方信息、买方信息、收货人信息、金融信息、发票信息、支付信息、快递信息、拣货信息等等），所有的业务属性都放在一张大表，也存在相应问题：
- 字段多，不好维护
- 单行数据量大，给性能较大造成影响
比较常见的一种垂直分表方法： 按业务类别分，比如： 订单主对象， 把金融信息、支付信息、收货人信息分出去，建成1对1字表。这样做优点是开发员好理解，缺点是查询时又得INNER JOIN回来，这样其实也就失去了垂直分表的最大意义（性能）。
从性能考虑（否则，后期很难优化），设计时垂直分表原则应该是：会作为查询条件的尽可能放在主表。哪怕重要信息但不作为查询条件的都可以放子表，更不用说数据量大的属性和不经常访问到的属性了。
在整个系统中，尽量不用到JOIN操作，基於单表的增删改查操作，entity访问（架构设计中如何做到呢？ 且听下回分解^_^）。