數據庫性能優化方案

不論MSYQL過程如何，最後都要到磁盤上去讀這個「文件」（記錄存儲區等效），因此固然這一切的前提是隻讀 內容，無關任何排序或查找操做。因此，讀寫任何類型的數據都沒有直接操做文件來的快。

判斷方法：

一、若是信息的及時性要求不高 能夠加入緩存來減小頻繁讀寫數據庫。

二、一次讀取的內容越大，直接讀文件的優點會越明顯

三、寫文件和INSERT幾乎不用測試就能夠推測出，數據庫效率只會更差。

四、很小的配置文件若是不須要使用到數據庫特性，更加適合放到獨立文件裏存取，無需單首創建數據表或記錄，很大的文件好比圖片、音樂等採用文件存儲更爲方便，只把路徑或縮略圖等索引信息放到數據庫裏更合理一些。

一、讀寫分離

隨着業務的發展，咱們的數據量和訪問量都在增加。對於大型網站來講，有很多業務是讀多寫少的，這個情況也會直接反應到數據庫上。那麼對於這樣的狀況，咱們能夠考慮使用讀寫分離的方式。

這個結構的變化會帶來兩個問題：

一、數據複製問題。

二、應用對於數據源的選擇問題。

咱們但願經過讀庫來分擔主庫上讀的壓力，那麼首先就須要解決數據怎麼複製到讀庫的問題。數據庫系統通常都提供了數據複製的功能，咱們能夠直接使用數據庫系統的自身機制。但對於數據複製，咱們還須要考慮數據複製時延問題，以及複製過程當中數據的源和目標之間的映射關係及過濾條件的支持問題。數據複製延遲帶來的就是短時間的數據不一致。例如咱們修改了用戶信息，在這個信息尚未複製到讀庫時（由於延遲），咱們從讀庫上讀出來的信息就不是最新的，若是把這個信息給進行修改的人看，就會讓他以爲沒有修改爲功。

對於應用來講，增長一個讀庫對結構變化有一個影響，即咱們的應用須要根據不一樣狀況來選擇不一樣的數據庫源。寫操做要走主庫，事務中的讀也要走主庫，而咱們也要考慮到備庫數據相對於主庫數據的延遲。就是說即使是不在事務中的讀，考慮到備庫的數據延遲，不一樣業務下的選擇也會有差別。

提到讀寫分離，咱們更多地是想到數據庫層面。事實上，廣義的讀寫分離能夠擴展到更多的場景。咱們看一下讀寫分離的特色。簡單來講就是在原有讀寫設施的基礎上增長了讀「庫」，更合適的說法應該是增長了讀「源」，由於它不必定是數據庫，而只是提供讀服務的，分擔原來的讀寫庫中讀的壓力。由於咱們增長的是一個讀「源」，因此須要解決向這個「源」複製數據的問題。

在這兒順便說一下搜索引擎。

以咱們所舉的交易網站爲例，商品存儲在數據庫中，咱們須要實現讓用戶查找商品的功能，尤爲是根據商品的標題來查找的功能。對於這樣的狀況，可能有讀者會想到數據庫中的like功能，這確實是一種實現方式，不過這種方式的代價也很大。還可使用搜索引擎的倒排表方式，它可以大大提高檢索速度。不管是經過數據庫仍是搜索引擎，根據輸入的內容找到符合條件的記錄以後，如何對記錄進行排序都是很重要的。

搜索引擎要工做，首要的一點是須要根據被搜索的數據來構建索引。隨着被搜索數據的變化，索引也要進行改變。這裏所說的索引能夠理解爲前面例子中讀庫的數據，只不過索引的是真實的數據而不是鏡像關係。而引入了搜索引擎以後，咱們的應用也須要知道什麼數據應該走搜索，什麼數據應該走數據庫。構建搜索用的索引的過程就是一個數據複製的過程，只不過不是簡單複製對應的數據。

搜索集羣（Search Cluster）的使用方式和讀庫的使用方式是同樣的。只是構建索引的過程基本都是須要咱們本身來實現的。

整體來講，搜索引擎的技術解決了站內搜索時某些場景下讀的問題，提供了更好的查詢效率。而且咱們看到的站內搜索的結構和使用讀庫是很是相似的，咱們能夠把搜索引擎當成一個讀庫。

二、擅用緩存

緩存（Cache Memory）位於與內存之間的臨時存儲器，它的容量比內存小但交換速度快。在緩存中的數據是內存中的一小部分，但這一小部分是短期內即將訪問的，當調用大量數據時，就可避開內存直接從緩存中調用，從而加快讀取速度。因而可知，在中加入緩存是一種高效的解決方案，這樣整個內存儲器（緩存+內存）就變成了既有緩存的高速度，又有內存的大容量的存儲系統了。緩存對的性能影響很大，主要是由於CPU的數據交換順序和CPU與緩存間的帶寬引發的。

  緩存是爲了解決CPU速度和內存速度的速度差別問題。內存中被CPU訪問最頻繁的數據和指令被複制入CPU中的緩存，這樣CPU就能夠不常常到象「蝸牛」同樣慢的內存中去取數據了，CPU只要到緩存中去取就好了，而緩存的速度要比內存快不少。 

  這裏要特別指出的是： 
  1.由於緩存只是內存中少部分數據的複製品，因此CPU到緩存中尋找數據時，也會出現找不到的狀況（由於這些數據沒有從內存複製到緩存中去），這時CPU仍是會到內存中去找數據，這樣系統的速度就慢下來了，不過CPU會把這些數據複製到緩存中去，以便下一次不要再到內存中去取。 

  2..由於隨着時間的變化，被訪問得最頻繁的數據不是一成不變的，也就是說，剛纔還不頻繁的數據，此時已經須要被頻繁的訪問，剛纔仍是最頻繁的數據，如今又不頻繁了，因此說緩存中的數據要常常按照必定的算法來更換，這樣才能保證緩存中的數據是被訪問最頻繁的。

三、專庫專用，數據垂直拆分

  讀寫分離後，數據庫又遇到瓶頸

垂直拆分的意思是把數據庫中不一樣的業務數據拆分到不一樣的數據庫中。結合如今的例子，就是把交易、商品、用戶的數據分開，如圖2-20所示。

這樣的變化給咱們帶來的影響是什麼呢？應用須要配置多個數據源，這就增長了所需的配置，不過帶來的是每一個數據庫鏈接池的隔離。不一樣業務的數據從原來的一個數據庫中拆分到了多個數據庫中，那麼就須要考慮如何處理原來單機中跨業務的事務。一種辦法是使用分佈式事務，其性能要明顯低於以前的單機事務；而另外一種辦法就是去掉事務或者不去追求強事務支持，則原來在單庫中可使用的表關聯的查詢也就須要改變實現了。

對數據進行垂直拆分以後，解決了把全部業務數據放在一個數據庫中的壓力問題。而且也能夠根據不一樣業務的特色進行更多優化。

四、分佈式存貯

常見的分佈式存儲系統有分佈式文件系統、分佈式Key-Value系統和分佈式數據庫。

 四、1 文件系統是你們所熟知的，分佈式文件系統就是在分佈式環境中由多個節點組成的功能與單機文件系統      同樣的文件系統，它是弱格式的，內容的格式須要使用者本身來組織；

 四、2 而分佈式Key-Value系統相對分佈式文件系統會更加格式化一些；

 四、3 分佈式數據庫則是最格式化的方式了。

分佈式存儲系統自身起到了存儲的做用，也就是提供數據的讀寫支持。相對於讀寫分離中的讀「源」，分佈式存儲系統更多的是直接代替了主庫。是否引入分佈式系統則須要根據具體場景來選擇。分佈式存儲系統經過集羣提供了一個高容量、高併發訪問、數據冗餘容災的支持。具體到前文提到的三個常見類，則是

 1、經過分佈式文件系統來解決小文件和大文件的存儲問題，

 2、經過分佈式Key-Value系統提供高性能的半結構化的支持，

 3、經過分佈式數據庫提供一個支持大數據、高併發的數據庫系統。

分佈式存儲系統能夠幫助咱們較好地解決大型網站中的大數據量和高併發訪問的問題。引入分佈式存儲系統後，咱們的系統大概會是圖2-19的樣子。