這幾年，各行各業的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訪問（架構設計中如何做到呢？ 且聽下回分解^_^）。