讓MySQL數據庫跑的更快 為數據減肥。本站提示廣大學習愛好者：（讓MySQL數據庫跑的更快 為數據減肥）文章只能為提供參考，不一定能成為您想要的結果。以下是讓MySQL數據庫跑的更快 為數據減肥正文
在數據庫優化任務中，使數據盡量的小，使表在硬盤上占領的空間盡量的小，這是最經常使用、也是最有用的手腕之一。由於減少數據，絕對來講可以進步硬盤的讀寫速度，而且在查詢進程中小表的內容處置時所占用的體系資本比擬少。同理，假如在比擬小的列上設置索引的話，其索引所占用的資本也會比擬少。那末數據庫治理員該若何給本身的數據減肥呢?對此筆者有以下幾個建議。
建議一：空值其實不必定不占用空間
在這裡筆者先給年夜家掃盲一下。有些數據庫治理員，以為空值不會占用體系資本，其實這是一個毛病的熟悉。他們在數據庫設計時，不愛好將字段的屬性設置為NOT NULL。而讓用戶依據本身的須要來輸出數據。筆者以為，這類做法關於數據庫的機能是晦氣的。
筆者的看法是，假如有能夠的話，盡可能將列設置為NOT NULL，即不許可有空值。這麼做的話，可以加速後續處置的速度，同時從數據存儲來看還可使得每列節儉一名，從而到達數據減肥的目標。在現實任務中，假如有些情形不須要用戶輸出數據時，還可以經由過程默許字段來到達非空的目標。如在薪資體系中，可以將用戶的任務年限默許設置為0，而不是空白。固然，假如確切須要NULL的話，也沒有方法。然則作為數據庫工程師來講，要盡可能防止應用NULL值。
建議二：應用盡可能小的數據類型
數據類型的年夜小也會影響到基本表的年夜小。如關於MEDIUMINT和INT兩個數據類型，其都可以用來保留整數型的數據，只是其可以或許保留的精度分歧罷了。然則從存儲數據的角度來看，前者所須要的存儲空間要比後者節儉25%閣下。為此在可以或許應用MEDIUMINT的情形下，就不要應用INT。
別的在界說數據長度的時刻，在知足需求的情形下，也要盡可能的短。如如今薪資考察體系中有員工編碼一個字段。假如企業員工編碼曾經肯定，有五位字符組成。那末在界說字段時，只須要界說5個字符的長度。這不只可以減少存儲空間，並且還可以起到必定的數據校訂功效。當用戶輸出的編碼長度跨越5位時，數據將沒法保留。
固然說保留某個數據可以有許多數據類型可以選擇，也能夠界說比擬年夜的字符位數。然則選擇盡可能小的數據類型，可以贊助下降數據存儲空間，到達數據減肥的目標。從而進一步晉升數據庫的機能。
建議三：索引與數據表年夜小的關系
筆者在文章一開首就談到過，假如關於比擬小的列設置索引，那末索引也將占用比擬少的資本。可見，索引與數據表年夜小也有慎密的接洽。在適合的處所、適合的機會設置適合的索引，也能夠完成對數據減肥的目標。
如平日情形下，每張數據表能夠會有多個索引，然則主索引常常只要一個。為此關於每張表的主索引應當斟酌盡可能的短小精干。這可以贊助數據庫更快的停止辨認。
再如盡可能對前綴停止索引。如如今有一張表，須要對某個列設置索引。而這個列有一個特色，即在頭幾個字符上有獨一的前綴。假如存在這類情形的話，那末牢牢索引這個前綴，而不是全體，後果會更好。在MySQL數據庫中，支撐對一個字符列的最右邊部門創立一個索引。這也就是說，數據庫會將某個字段依據必定的規矩拆分為前後兩個部門。拆分後後面一部門的數據假如可以或許堅持獨一，那末就只須要對後面一部門設置索引便可，而不須要對全部字段的數據設置索引。這無疑可以減少索引所占用的資本，完成減肥的目標。更短的索引，可以或許供給更快的查詢速度。由於它們所占用的硬盤空間更少，並且他們將在索引緩存中保留更多的拜訪。從而下降硬盤的搜刮次數，進步查詢的效力。
最初須要留意的就是，索引不克不及夠濫用。應用索引確切可以進步數據的處置才能，然則索引同時也會帶來額定的開支。只要這個收益年夜於開支時，應用索引能力夠晉升數據庫的機能。不然的話，則會起到相反的後果。如某個表須要停止疾速的存儲，假如在這個表上設置過量的索引，索引就會起到反作用。對此筆者建議，假如重要經由過程搜刮列的組合來存取一個表，那末最好對他們只設置一個索引。固然，這個索引部門應當是平常任務中最經常使用的列。在不得已的情形下，假如須要應用多個索引的話，那末最好可以或許以更多的正本應用列來取得更好的索引緊縮。從而下降由於應用了多個索引而增長的資本消費。
建議四：在須要“飽滿”的處所照樣不克不及夠節儉
一個女人，該瘦的處所要瘦，該飽滿的處所要飽滿。其實數據庫也是如斯。可以或許節儉硬盤空間的處所，就要節儉。而不克不及夠節儉的處所，則不克不及夠為了減肥而將其精簡上去。有時刻這會起到拔苗助長的後果。
筆者以Varchar為例。如在MyISAM標中，假如沒有任何可變長的列，那末最好應用固定年夜小的數據類型。固然采取固定長度的數據類型，常常會糟蹋必定的存儲空間。由於假如用戶輸出的數據缺乏，采取固定長度的話，數據存儲時依然會按這個固定的長度來存儲。然則在這類情形下，可以或許用固定長度的，照樣要應用固定長度。由於這類情形下固然會糟蹋必定的硬盤空間，然則卻可以進步數據的查詢速度。
可見，其實不是在任何情形下對數據減肥都可以進步數據庫的機能。這就似乎節支開源，這個節儉要節儉在刀刃上。不然的話，不只不克不及夠節支，並且還會搬起石頭砸本身的腳。淺顯的說，就是該瘦的處所要瘦，該飽滿的處所要飽滿。記住這句話，就對了。
建議五：將表朋分以完成減肥的目標
螞蟻在搬食品時，假如某塊食品過年夜，沒法挪動轉移的話，螞蟻則能夠會將這個塊食品停止朋分，直到其搬得動為止。這就是分蛋糕道理。其實這類景象在平常任務中常常罕見。如我們有一張數據庫表格，假如外面的記載異常多，那末表格的許可速度會異常的慢。在這類情形下，可以依據必定的規矩將表分為多個任務簿。如如今有一份企業員工的考勤信息。對這個表停止查詢、排序、統計時，期待時光異常的長。此時便可以依據部分將其朋分成分歧的任務簿，然後再對其停止相干的數據剖析。此時固然任務量會年夜一點，然則其處置的速度會變快很多。
依據這個道理，在數據庫優化時，可以將一個常常被掃描的年夜表朋分為2個或許2個以上的表現異常無益的。如在平常任務中，筆者如今有一個靜態格局的數據表，而且這個數據是應用一個掃描表時，就會用這個來找出相干行的比擬小的靜態格局的表。
經由過程這個表的拆分，可以將一塊年夜蛋糕分為幾塊小的蛋糕，以利於後續數據的統計與剖析。固然這個後果的利害，直接跟這個拆分的規矩有關。關於表若何拆分能力夠到達幻想的後果，這又是一個比擬年夜的話題。因為這裡篇幅無限，筆者不做過量的解釋。也許在後續的文章中，筆者會以這命題停止睜開，給年夜家做具體的解釋。
原文出處：http://publish.itpub.net/a2011/0302/1161/000001161945.shtml
