背景： 對於存在有問題的項目（包括 代碼不規範 數據庫表命名不規範 ）需要改造
系統業務架構：
步驟：
1 新建工程 ： 將需要改造的項目拷貝一份 修改項目名稱
2 將相應的表結構拷貝到新的數據庫中 修改不直觀的表名 字段的備註等
3 修改對應的代碼 和數據庫表字段對應 熟悉接口對應的相關類 找到與之相關的
注意：
1 併發冪等性（重試引起）控制
2 方法設置開關
3 金額存整數（元化爲分）
4 解耦 （rocketMQ消息異步解耦）
加入狀態機【待完成】
5 分庫【垂直拆分 基本的思路就是按照業務模塊來劃分出不同的數據庫】
分表【垂直拆分某個表中的字段比較多，可以新建立一張“擴展表”，將不經常使用或者長度較大的字段拆分出去放到“擴展表”中】
好處： 便於 管理、維護、監控、擴展 ，在高併發場景下，垂直分庫一定程度上能夠突破IO、連接數及單機硬件資源的瓶頸，是大型分佈式系統中優化數據庫架構的重要手段。
注意：需要改寫以前的查詢語句【跨庫join，分佈式事務等】
跨庫Join的幾種解決思路
1 全局表【很少發生編號 像數據字典】
系統中所有模塊都可能會依賴到的一些表，將這類表在其他每個數據庫中均保存一份
2 字段冗餘 【最複雜的還是數據一致性問題，這點很難保證】
3 數據同步
定時A庫中的tab_a表和B庫中tbl_b有關聯，可以定時將指定的表做同步，通過ETL工具來實施
4 系統層組裝
在系統層面，通過調用不同模塊的組件或者服務，獲取到數據並進行字段拼裝
注意：把循環調用改成一次調用【通常我們都會通過緩存來避免頻繁RPC通信和數據庫查詢的開銷】
join 查詢帶條件過濾的情況
查詢出state字段符合/不符合的UserId，在查詢問答數據的時候使用in/not in進行過濾，排序，分頁等。過濾出有效的問答
數據後，再調用用戶服務獲取數據進行組裝
6 考慮問題轉換思路 ： 記得兩方面着手 1 數據庫層面【善於利用僞列】 2 代碼層面
水平分表，能夠降低單表的數據量，一定程度上可以緩解查詢性能瓶頸。但本質上這些表還保存在同一個庫中，所以庫級別還是會有IO瓶頸。 所以，一般不建議採用這種做法
忽略配置文件被跟蹤的另一種方法：
$ git update-index --assume-unchanged /path/to/file #忽略跟蹤
$ git update-index --no-assume-unchanged /path/to/file #恢復跟蹤模型： 領域模型 倉儲模型
7 記錄好追蹤日誌
eclipse裏groovy 插件地址：http://dist.springsource.org/release/GRECLIPSE/e4.7