應用類型

示例

總體概況

SQL 特點

大量存量業務的應用

某醫療公司或醫院已使用10+年的業務系統，系統存在大量舊業務。

• 存量業務的庫表非常多。

• 庫數目≥10或表數目≥100。

• 業務SQL查詢的種類復雜多樣。

• 應用遇到單機資源瓶頸，業務查詢響應時間的越來越慢，需要優化。

• 數據庫要服務大量的老舊應用，存在眾多歷史業務的數據庫或業務表，并且庫表數量很大。

• 存在大量業務老舊復雜SQL，且不能修改。

混合存量業務與新業務的應用

某經營多年的商家訂單管理系統，且系統要開發新功能。

• 存量業務庫表眾多。

• 庫數目≥2或表數目≥10。

• 新業務：業務有大表且數據增長快，單機資源即將不足，需要擴展。

• 業務庫表數目偏多。

• 存在大量存量業務SQL，且大部分不能修改。

• 新業務的部分大表及SQL接受改造及優化。

基于單機MySQL 開發的新業務應用

某攝影公司新開發的業務系統，需要快速上線。

• 庫表數目較少，業務規模較小。

• 庫數目<2或表數目<10。

• 預期未來的數據增量較大，需要擴展性。

• 業務初期追求快速上線，后期會快速迭代優化。

• 新業務的庫表及SQL能接受改造及調整優化。

高性能高吞吐的業務應用

某大型電商的核心交易系統。

• 庫表數目不多，但數據規模大，高并發。

• 應用對SQL查詢RT極為敏感。

• 非常重視業務整體的吞吐性能。

• SQL查詢種類不多，且相對固定。

• SQL查詢的并發高，且要求查詢性能穩定。

應用類型

優化目標

改造挑戰點

推薦工作模式

給應用帶來的業務效果

大量存量老業務的應用

• 突破單機資源瓶頸（主要是CPU/IO）。

• 優化SQL查詢RT。

• 歷史存量業務的庫表數目過多（庫表數目可能達百級或千級），庫表的JOIN關系錯綜復雜。

• 業務原來的SQL查詢復雜多樣，不允許修改，對分布式數據庫的SQL兼容性高。

單表打散

• 最大限度地保持對原有從多存量業務庫表及其 SQL的兼容性與查詢性能。

• 眾多單表被打散到不同的DN節點，突破單機資源瓶頸，實現負載均衡與性能提升。

混合存量業務與新業務的應用

• 突破單機資源瓶頸（主要是CPU/IO/DISK瓶頸 ）。

• 業務SQL查詢性能盡量不回退。

• 大表的磁盤空間擴展。

• 歷史存量業務的庫表很多，庫表JOIN關系錯綜復雜。

• 存量業務原有SQL查詢復雜多樣，大部分不允許修改。

• 部分新業務庫表，尤其是大表，數據量增長快。

單表打散+手動分區

• 最大限度地保持對原有從多存量業務庫表及SQL 的兼容性與查詢性能。

• 眾多單表被打散到不同的DN節點，突破單機資源瓶頸，實現負載均衡與性能提升。

• 業務大表手動分區，在解決擴展性的同時，保證讀寫性能。

基于單機 MySQL開發的新業務應用

• 需要擴展性。

• 業務性能要求不高。

• 業務要盡量減少改造成本，需要快速上線。

自動分區

• 所有表自動分區，能突破單機資源瓶頸。

• 所有索引默認全局索引，保證非主鍵維度查詢的基本性能。

高性能高吞吐的業務應用

• 需要線性擴展。

• 高性能。

• 業務并發量大（幾萬或幾十萬QPS），并要求線性擴展。

• 業務對性能敏感，SQL查詢要求快且穩定。

手動分區

• 所有表均按業務場景，手動選擇最合理的分區方案。

• 業務查詢SQL能改造，滿足線性擴展性。