讓MySQL資料庫跑的更快 為資料減肥

來源:互聯網
上載者:User

在資料庫最佳化工作中,使資料儘可能的小,使表在硬碟上佔據的空間儘可能的小,這是最常用、也是最有效手段之一。因為縮小資料,相對來說可以提高硬碟的讀寫速度,並且在查詢過程中小表的內容處理時所佔用的系統資源比較少。同理,如果在比較小的列上設定索引的話,其索引所佔用的資源也會比較少。那麼資料庫管理員該如何給自己的資料減肥呢?對此筆者有如下幾個建議。

建議一:空值並不一定不佔用空間

在這裡筆者先給大家掃盲一下。有些資料庫管理員,認為空白值不會佔用系統資源,其實這是一個錯誤的認識。他們在資料庫設計時,不喜歡將欄位的屬性設定為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

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.