怎么給自己的讓MySQL數據庫減肥

這篇文章將為大家詳細講解有關怎么給自己的讓MySQL數據庫減肥，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

　　數據庫優(yōu)化工作中，使數據盡可能的小，使表在硬盤上占據的空間盡可能的小，這是最常用、也是最有效的手段之一。因為縮小數據，相對來說可以提高硬盤的讀寫速度，并且在查詢過程中小表的內容處理時所占用的系統資源比較少。同理，如果在比較小的列上設置索引的話，其索引所占用的資源也會比較少。那么數據庫管理員該如何給自己的數據減肥呢?下面億速云小編來講解下數據庫管理員該如何給自己的讓MySQL數據庫減肥?

　　數據庫管理員該如何給自己的讓MySQL數據庫減肥

　　建議一：空值并不一定不占用空間

　　在這里筆者先給大家掃盲一下。有些數據庫管理員，認為空值不會占用系統資源，其實這是一個錯誤的認識。他們在數據庫設計時，不喜歡將字段的屬性設置為NOTNULL。而讓用戶根據自己的需要來輸入數據。筆者認為，這種做法對于數據庫的性能是不利的。

　　筆者的意見是，如果有可能的話，盡量將列設置為NOTNULL，即不允許有空值。這么做的話，可以加快后續(xù)處理的速度，同時從數據存儲來看還可以使得每列節(jié)省一位，從而達到數據減肥的目的。在實際工作中，如果有些情況不需要用戶輸入數據時，還可以通過默認字段來達到非空的目的。如在薪資系統中，可以將用戶的工作年限默認設置為0，而不是空白。當然，如果確實需要NULL的話，也沒有辦法。但是作為數據庫工程師來說，要盡量避免使用NULL值。

　　建議二：使用盡量小的數據類型

　　數據類型的大小也會影響到基礎表的大小。如對于MEDIUMINT和INT兩個數據類型，其都可以用來保存整數型的數據，只是其能夠保存的精度不同而已。但是從存儲數據的角度來看，前者所需要的存儲空間要比后者節(jié)省25%左右。為此在能夠使用MEDIUMINT的情況下，就不要使用INT。

　　另外在定義數據長度的時候，在滿足需求的情況下，也要盡量的短。如現在薪資考核系統中有員工編碼一個字段。如果企業(yè)員工編碼已經確定，有五位字符構成。那么在定義字段時，只需要定義5個字符的長度。這不僅可以縮小存儲空間，而且還可以起到一定的數據校對功能。當用戶輸入的編碼長度超過5位時，數據將無法保存。

　　雖然說保存某個數據可以有很多數據類型可以選擇，也可以定義比較大的字符位數。但是選擇盡量小的數據類型，可以幫助降低數據存儲空間，達到數據減肥的目的。從而進一步提升數據庫的性能。

　　數據庫管理員該如何給自己的讓MySQL數據庫減肥

　　建議三：索引與數據表大小的關系

　　筆者在文章一開頭就談到過，如果對于比較小的列設置索引，那么索引也將占用比較少的資源?？梢?，索引與數據表大小也有緊密的聯系。在合適的地方、合適的時機設置合適的索引，也可以實現對數據減肥的目的。

　　如通常情況下，每張數據表可能會有多個索引，但是主索引往往只有一個。為此對于每張表的主索引應該考慮盡量的短小精悍。這可以幫助數據庫更快的進行識別。

　　再如盡量對前綴進行索引。如現在有一張表，需要對某個列設置索引。而這個列有一個特點，即在頭幾個字符上有唯一的前綴。如果存在這種情況的話，那么緊緊索引這個前綴，而不是全部，效果會更好。在MySQL數據庫中，支持對一個字符列的最左邊部分創(chuàng)建一個索引。這也就是說，數據庫會將某個字段根據一定的規(guī)則拆分為前后兩個部分。拆分后前面一部分的數據如果能夠保持唯一，那么就只需要對前面一部分設置索引即可，而不需要對整個字段的數據設置索引。這無疑可以縮小索引所占用的資源，實現減肥的目的。更短的索引，能夠提供更快的查詢速度。因為它們所占用的硬盤空間更少，而且他們將在索引緩存中保存更多的訪問。從而降低硬盤的搜索次數，提高查詢的效率。

　　最后需要注意的就是，索引不能夠濫用。使用索引確實可以提高數據的處理能力，但是索引同時也會帶來額外的開銷。只有這個收益大于開銷時，使用索引才能夠提升數據庫的性能。否則的話，則會起到相反的效果。如某個表需要進行快速的存儲，如果在這個表上設置過多的索引，索引就會起到副作用。對此筆者建議，如果主要通過搜索列的組合來存取一個表，那么最好對他們只設置一個索引。當然，這個索引部分應該是日常工作中最常用的列。在不得已的情況下，如果需要使用多個索引的話，那么最好能夠以更多的副本使用列來獲得更好的索引壓縮。從而降低因為使用了多個索引而增加的資源消耗。

　　建議四：在需要“豐滿”的地方還是不能夠節(jié)省

　　一個女人，該瘦的地方要瘦，該豐滿的地方要豐滿。其實數據庫也是如此。能夠節(jié)省硬盤空間的地方，就要節(jié)省。而不能夠節(jié)省的地方，則不能夠為了減肥而將其精簡下來。有時候這會起到適得其反的效果。

　　筆者以Varchar為例。如在MyISAM標中，如果沒有任何可變長的列，那么最好使用固定大小的數據類型。雖然采用固定長度的數據類型，往往會浪費一定的存儲空間。因為如果用戶輸入的數據不足，采用固定長度的話，數據存儲時仍然會按這個固定的長度來存儲。但是在這種情況下，能夠用固定長度的，還是要使用固定長度。因為這種情況下雖然會浪費一定的硬盤空間，但是卻可以提高數據的查詢速度。

　　可見，并不是在任何情況下對數據減肥都可以提高數據庫的性能。這就好像節(jié)支開源，這個節(jié)省要節(jié)省在刀刃上。否則的話，不但不能夠節(jié)支，而且還會搬起石頭砸自己的腳。通俗的說，就是該瘦的地方要瘦，該豐滿的地方要豐滿。記住這句話，就對了。

　　建議五：將表分割以實現減肥的目的

　　螞蟻在搬食物時，如果某塊食物過大，無法搬動的話，螞蟻則可能會將這個塊食物進行分割，直到其搬得動為止。這就是分蛋糕原理。其實這種現象在日常工作中經常常見。如我們有一張數據庫表格，如果里面的紀錄非常多，那么表格的允許速度會非常的慢。在這種情況下，可以根據一定的規(guī)則將表分為多個工作簿。如現在有一份企業(yè)員工的考勤信息。對這個表進行查詢、排序、統計時，等待時間非常的長。此時就可以根據部門將其分割成不同的工作簿，然后再對其進行相關的數據分析。此時雖然工作量會大一點，但是其處理的速度會變快許多。

　　根據這個原理，在數據庫優(yōu)化時，可以將一個經常被掃描的大表分割為2個或者2個以上的表示非常有益的。如在日常工作中，筆者現在有一個動態(tài)格式的數據表，并且這個數據是使用一個掃描表時，就會用這個來找出相關行的比較小的靜態(tài)格式的表。

　　通過這個表的拆分，可以將一塊大蛋糕分為幾塊小的蛋糕，以利于后續(xù)數據的統計與分析。當然這個效果的好壞，直接跟這個拆分的規(guī)則有關。關于表如何拆分才能夠達到理想的效果，這又是一個比較大的話題。由于這里篇幅有限，筆者不做過多的說明。或許在后續(xù)的文章中，筆者會以這命題進行展開，給大家做詳細的說明。

關于怎么給自己的讓MySQL數據庫減肥就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。