一、環境
RDS：MySQL
RDS-Proxy：ShardingSphereProxy
二、場景描述
在項目中有一些歷史表，使用了聯合主鍵，這裏列舉一部分聯合主鍵的缺點：
- 跟業務耦合 一般使用聯合主鍵，都是跟着業務走，比如使用org_code、biz_code這種模式，違背了數據庫設計三大原則
- 非順序 因爲MySQL8採用InnoDB（MyISam過時），底層使用了B+樹和聚集索引，當順序寫入時，葉分裂只會在尾部，影響範圍較小，但當數據在中間插入，就會造成中間葉分裂，重平衡消耗很大
- 空間佔用大 因爲使用業務方提供的業務編碼作爲聯合主鍵，通常長度設置得非常長，當聯合主鍵佔用空間大，意味着一次加載數據頁佔用就越大，在相同數據量時更快地向更深層的樹發展
三、解決方案
場景：
- 不分片 新增id字段，並設置爲主鍵，將聯合主鍵更改爲聯合唯一索引
- 分片
- 估計分片最大數據量
- 以最大數據量爲基點 + 未來最大數據量（無法估計默認爲億）
- 數據庫設置爲自增
- 設置自增起始值爲數據分片前綴 + 最大數據量抹零（000000000） = 100_000000000
- 去掉數據庫自增
說明：此處是作爲初始化主鍵方案，後續會使用snowflake算法來作爲主鍵生成策略，本方案適用在此場景，不同場景需要自定義