數據庫優化的階段是什么

這篇文章主要講解了“數據庫優化的階段是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“數據庫優化的階段是什么”吧！

0x01：SQL優化及應用程序優化

一個系統總是從小到大，所以在系統還是小型系統的時候。首先應該注重表的設計，合理使用主鍵、外鍵、索引；字段選用合適的數據類型、合適的數據長度。使用SQL考慮索引什么情況是有效的；什么時候是失效的，避免使用索引失效的SQL。

另外應該程序優化也很重要，比如能批量執行SQL，就不要在程序中循環執行SQL。使用各種框架的緩存也非常重要，例如，如果使用MyBatis時，就好合理使用MyBatis的一級緩存和二級緩存；使用Hibernate時，就好合理使用Hibernate的一級緩存和二級緩存等。

0x02：數據庫讀寫分類

當業務量達到一定程度時，可以考慮數據庫的讀寫分離方案，讓讀寫業務分離。但是一定要考慮如何解決寫庫與讀庫的數據一致性問題。目前，很多開源的讀寫分離服務和框架。主要基于如下兩種方案：

• 應用程序根據業務邏輯來判斷，增刪改等寫操作命令發給寫庫，查詢命令發給讀庫。

• 利用中間件來做代理，負責對數據庫的請求識別出讀還是寫，并分發到不同的數據庫中。

0x03：引入緩存數據庫

NoSQL數據庫目前也是大行其道，特別Redis數據庫。例如使用Redis緩存服務器，可以把一些常用、不經常變化的數據緩存到內存。在內存讀取數據的數據要比在硬盤讀取的速度不知道快多少倍。引入緩存數據庫增加了系統的復雜度，另外還有考慮關系型數據庫與NoSQL數據庫數據一致性的問題。

0x04：垂直拆分

一個數據庫由很多表的構成，每個表對應著不同的業務，垂直切分是指按照業務將表進行分類，分布到不同的數據庫上面，這樣也就將數據或者說壓力分擔到不同的庫上面，如下圖：

優點：

• 拆分后業務清晰，拆分規則明確

• 系統之間整合或擴展容易

• 數據維護簡單

缺點：

• 部分業務表無法join，只能通過接口方式解決，提高了系統復雜度

• 受每種業務不同的限制存在單庫性能瓶頸，不易數據擴展跟性能提高

• 事務處理復雜

0x05：水平拆分

垂直拆分后遇到單機瓶頸，可以使用水平拆分。相對于垂直拆分的區別是：垂直拆分是把不同的表拆到不同的數據庫中，而水平拆分是把同一個表拆到不同的數據庫中。

相對于垂直拆分，水平拆分不是將表的數據做分類，而是按照某個字段的某種規則來分散到多個庫之中，每個表中包含一部分數據。簡單來說，我們可以將數據的水平切分理解為是按照數據行的切分，就是將表中 的某些行切分到一個數據庫，而另外的某些行又切分到其他的數據庫中，主要有分表，分庫兩種模式。如下圖：

分庫模式

分表模式

優點：

• 不存在單庫大數據，高并發的性能瓶頸

• 對應用透明，應用端改造較少

• 按照合理拆分規則拆分，join操作基本避免跨庫

• 提高了系統的穩定性跟負載能力

缺點：

• 拆分規則難以抽象

• 分片事務一致性難以解決

• 數據多次擴展難度跟維護量極大

• 跨庫join性能較差

感謝各位的閱讀，以上就是“數據庫優化的階段是什么”的內容了，經過本文的學習后，相信大家對數據庫優化的階段是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！