原文鏈接：https://www.modb.pro/db/25251 （復制鏈接至瀏覽器，即可查看）
常常會問道，怎樣使用MySQL能達到高性能。以下內容是結合其他技術同仁的總結和自我實踐整理的20個開源數據庫設計原則。
一、開源數據庫架構設計原則 1.1. 技術選型 選擇成熟的平臺和技術，同時是最熟悉的，能做到極致的，用好不用壞，用熟不用生。目前業界的MySQL主流分支版本有Oracle官方版本的MySQL、Percona Server、MariaDB。
1.2. 高可用選擇 高可用解決方案的探討本質上探討的是低宕機時間解決方案，可以理解為高可用的反面是不可用，絕大部分情況下數據庫宕機才會導致數據庫的不可用。隨著技術發展，開源數據庫方面很多高可用組件（主從復制，半同步，MGR，MHA，Galera Cluster）,對應場景，只有適合的，沒有萬能的，需要理解每個高可用優缺點。
1.3. 表設計 表設計方面目前為止一致堅持和提倡原則：
- 單表數據量
所有表都需要添加注釋，單表數據量建議控制在 3000 萬以內 - 不保存大字段數據
不在數據庫中存儲圖片、文件等大數據 - 表使用規范
拆分大字段和訪問頻率低的字段，分離冷熱數據
單表字段數控制在 20 個以內 - 索引規范
1.單張表中索引數量不超過 5 個
2.單個索引中的字段數不超過 5 個
3.INNODB 主鍵推薦使用自增列，主鍵不應該被修改，字符串不應該做主鍵，
如果不指定主鍵，INNODB 會使用唯一且非空值索引代替
4.如果是復合索引，區分最大的字段放在索引前面
5. 避免冗余或重復索引：合理創建聯合索引（避免冗余）
6. 不在低基數列上建立索引，例如‘性別’
7. 不在索引列進行數學運算和函數運算 - 字符集utf8mb4(偏生字，表情符)
1.4. 優化原則
1.5. 復制方式 MySQL復制方式提供異步方式，半同步方式，全局事務強一致性，binglog同步。需要不同業務系統間 或 兩個數據庫間進行同步。異步方式可以防止故障和效率問題的蔓延，擴大化，但強一致性會更復雜，并發，事務大小都有求限制。
1.6. 分離原則 區分核心的業務，重要業務，渠道，內部業務的業務系統，對不同的系統設置不同的架構。為核心業務設置 最佳為分庫，多活 專用高速公路，其他業務可以做讀寫分離，緩存
1.7. 擴展性 對于系統來說擴展性很重要，盡量做到水平擴展。避免過度依賴縱向擴展，同時具備縱向，橫向擴展的能力，例如無狀態應用應該多套負載均衡多活部署，數據庫分庫架構。
1.8. 讀寫分離
- 讀多寫少場景（10%寫 90%讀）
- 復制存在延遲，業務對延遲不敏感的
- 實現方式：通過應用代碼配置讀寫分離，
通過中間代理方式路由只讀庫 &
業務和數據庫為一個單位
1.9. 分庫分表
- 當表中數據記錄的數量超過3000萬條，再好的索引也已經不能提高數據查詢的速度，這時需要將表拆分成更多的小表，增加性能，增加彈性，避免發生垮庫進行操作。
- 引入中間價要考慮性能代價,聚合需求。
- 分庫原則盡量在App 上層進行分庫，就是流量
- 分多少合適：可用性和性能滿足TPS
- 路由：寫入配置文件 或則 插表 或則 zookeeper
1.10. 歸檔原則 歷史數據定期進行歸檔 或則 移到其他大數據平臺。能讓輕量級數據庫更多緩存有用的數據。 在MySQL分區表里 注意要避免分區鎖，只能寫讀的場景。
1.11. 連接池的要求 長鏈接，自動重鏈，延時和異常記錄， 彈性鏈接，檢測滿，異常告警，進階要求 是記錄所有訪問情況，可以擴展出很多能力。 應用和數據庫連接池設置，數據庫允許的連接數設置，常見問題。 A ）應用的數據庫連接池設置偏小，一旦數據庫相應慢（新上線應用，缺少索引 等）則應。 用排隊嚴重，甚至雪崩，而遺憾的是數據庫能力還遠為用盡。 B ）不具備失效及時發現和重新鏈接數據庫能力。 C ）隔離級別設置：RR 和 RC下不同的表現。
1.12. 應用解耦 通過應用訪問數據庫而不是直接訪問，重要業務不能依賴低保障級別的系統，應用層重要業務和普通業務解耦，關鍵業務要獨立。
1.13. 組件失效免疫能力 單一應用，單一硬件，甚至單一基礎設施，單一站點容災，業務影響，故障恢復能力，要季度級別進行演練。
1.14. 為關鍵組件減負 特別是數據庫訪問,數據庫成本最高，擴展性最難，可用性保障最難，恢復難度和時間最大。 減負：能不用就不用，使用最簡單，成本最低的語句，避免大事務，慎用兩階段事務。
1.15. 建議灰度數據庫 減少發布時變更數據庫對全局的影響,只有應用程序灰度是不夠的，還要有專門的灰度數據庫。在分庫、讀寫分離架構下，一套含數據庫的完整應用架構，變的很自然。 所為灰度環境就是生產環境，生產數據，所影響的也是生產環境，只是范圍比測試環境更廣，更真實。其實就是小范圍的生產環境。類似于游戲內測。
1.16. 建立高仿真架構體系
- 數據庫，操作系統升級：應用是否適應，性能會變好， 還是變壞
- 應用上線發布，系統變更（列如換平臺），提前判斷業務影響和性能瓶頸
- 應對突發交易量，例如雙十一，性能極限在哪里，瓶頸在哪里。
1.17. 容災保障 高可用是運維核心要求，容災是最后屏障 例如 雙活比單活好，MGR比復制架構好，重要系統要做好高可用，容災建設。
1.18. 多中心建設 冗余是基礎，多中心建設是為了提升容災能力和擴展能力，并保障業務。
1.19. 應用和數據庫是一個整體 應用和運維人員一起，解決應用解耦，數據庫解耦，追賬補數，業務監控，應用路由，故障切換等。可用性，效率，故障恢復等方面都要一起參與。
1.20. 性能提升 開源數據庫使用應該合理且有效的結合周邊的其他類型數據庫，做到性能最大化。比如：redis，MongoDB，ES，ClickHouse等。
二、總結 最適合的架構是結合軟件特性和業務場景，又能取得成本收益平衡。 大數據情況下可以是利用讀寫分離，分庫分表，但要選擇合適的。 不適合分庫的應該考慮 竭盡所能把核心庫做小，然后通過垂直擴展來擴容。 用盡各種技術， 高可用 和 容災手段保證其可用。
