最近玩家**性增長，使得原來設計的ws和資料庫那塊承受了更大的壓力，開始有點受不住了，於是理所當然的優化開始了。。。
這裡說幾個資料庫優化的建議和方法：
在資料庫優化工作中，使資料盡可能的小，使表在硬碟
上佔據的空間盡可能的小，這是最常用、也是最有效的手段之一。因為縮小資料，相對來說可以提高硬碟
的讀寫速度，並且在查詢過程中小表的內容處理時所占用的系統資源比較少。同理，如果在比較小的列上設定索引的話，其索引所占用的資源也會比較少。那麼資料庫管理員該如何給自己的資料**呢?對此筆者有如下幾個建議。
建議一：空值並不一定不占用空間
在這裡筆者先給大家掃盲一下。有些資料庫管理員，認為空值不會占用系統資源，其實這是乙個錯誤的認識。他們在資料庫設計時，不喜歡將字段的屬性設定為not null。而讓使用者根據自己的需要來輸入資料。筆者認為，這種做法對於資料庫的效能是不利的。
筆者的意見是，如果有可能的話，盡量將列設定為not null，即不允許有空值。這麼做的話，可以加快後續處理的速度，同時從資料儲存來看還可以使得每列節省一位，從而達到資料**的目的。在實際工作中，如果有些情況不需要使用者輸入資料時，還可以通過預設欄位來達到非空的目的。如在薪資系統中，可以將使用者的工作年限預設設定為0，而不是空白。當然，如果確實需要null的話，也沒有辦法。但是作為資料庫工程師來說，要盡量避免使用null值。
建議二：使用盡量小的資料型別
資料型別的大小也會影響到基礎表的大小。如對於mediumint和int兩個資料型別，其都可以用來儲存整數型的資料，只是其能夠儲存的精度不同而已。但是從儲存資料的角度來看，前者所需要的儲存空間要比後者節省25%左右。為此在能夠使用mediumint的情況下，就不要使用int。
另外在定義資料長度的時候，在滿足需求的情況下，也要盡量的短。如現在薪資考核系統中有員工編碼乙個字段。如果企業員工編碼已經確定，有五位字元構成。那麼在定義欄位時，只需要定義5個字元的長度。這不僅可以縮小儲存空間，而且還可以起到一定的資料校對功能。當使用者輸入的編碼長度超過5位時，資料將無法儲存。
雖然說儲存某個資料可以有很多資料型別可以選擇，也可以定義比較大的字元位數。但是選擇盡量小的資料型別，可以幫助降低資料儲存空間，達到資料**的目的。從而進一步提公升資料庫的效能。
建議三：索引與資料表大小的關係
筆者在文章一開頭就談到過，如果對於比較小的列設定索引，那麼索引也將占用比較少的資源。可見，索引與資料表大小也有緊密的聯絡。在合適的地方、合適的時機設定合適的索引，也可以實現對資料**的目的。
如通常情況下，每張資料表可能會有多個索引，但是主索引往往只有乙個。為此對於每張表的主索引應該考慮盡量的短小精悍。這可以幫助資料庫更快的進行識別。
再如盡量對字首進行索引。如現在有一張表，需要對某個列設定索引。而這個列有乙個特點，即在頭幾個字元上有唯一的字首。如果存在這種情況的話，那麼緊緊索引這個字首，而不是全部，效果會更好。在mysql資料庫中，支援對乙個字元列的最左邊部分建立乙個索引。這也就是說，資料庫會將某個字段根據一定的規則拆分為前後兩個部分。拆分後前面一部分的資料如果能夠保持唯一，那麼就只需要對前面一部分設定索引即可，而不需要對整個欄位的資料設定索引。這無疑可以縮小索引所占用的資源，實現**的目的。更短的索引，能夠提供更快的查詢速度。因為它們所占用的硬碟空間更少，而且他們將在索引快取中儲存更多的訪問。從而降低硬碟的搜尋次數，提高查詢的效率。
建議四：在需要「豐滿」的地方還是不能夠節省
乙個女人，該瘦的地方要瘦，該豐滿的地方要豐滿。其實資料庫也是如此。能夠節省硬碟空間的地方，就要節省。而不能夠節省的地方，則不能夠為了**而將其精簡下來。有時候這會起到適得其反的效果。
筆者以varchar為例。如在myisam標中，如果沒有任何可變長的列，那麼最好使用固定大小的資料型別。雖然採用固定長度的資料型別，往往會浪費一定的儲存空間。因為如果使用者輸入的資料不足，採用固定長度的話，資料儲存時仍然會按這個固定的長度來儲存。但是在這種情況下，能夠用固定長度的，還是要使用固定長度。因為這種情況下雖然會浪費一定的硬碟空間，但是卻可以提高資料的查詢速度。
可見，並不是在任何情況下對資料**都可以提高資料庫的效能。這就好像節支開源，這個節省要節省在刀刃上。否則的話，不但不能夠節支，而且還會搬起石頭砸自己的腳。通俗的說，就是該瘦的地方要瘦，該豐滿的地方要豐滿。記住這句話，就對了。
建議五：將表分割以實現**的目的
螞蟻在搬食物時，如果某塊食物過大，無法搬動的話，螞蟻則可能會將這個塊食物進行分割，直到其搬得動為止。這就是分蛋糕原理。其實這種現象在日常工作中經常常見。如我們有一張資料庫**，如果裡面的紀錄非常多，那麼**的允許速度會非常的慢。在這種情況下，可以根據一定的規則將表分為多個工作簿。如現在有乙份企業員工的考勤資訊。對這個表進行查詢、排序、統計時，等待時間非常的長。此時就可以根據部門將其分割成不同的工作簿，然後再對其進行相關的資料分析。此時雖然工作量會大一點，但是其處理的速度會變快許多。
根據這個原理，在資料庫優化時，可以將乙個經常被掃瞄的大表分割為2個或者2個以上的表示非常有益的。如在日常工作中，筆者現在有乙個動態格式的資料表，並且這個資料是使用乙個掃瞄表時，就會用這個來找出相關行的比較小的靜態格式的表。
通過這個表的拆分，可以將一塊大蛋糕分為幾塊小的蛋糕，以利於後續資料的統計與分析。當然這個效果的好壞，直接跟這個拆分的規則有關。關於表如何拆分才能夠達到理想的效果，這又是乙個比較大的話題。由於這裡篇幅有限，筆者不做過多的說明。或許在後續的文章中，筆者會以這命題進行展開，給大家做詳細的說明。
資料庫伺服器優化
1.為查詢優化你的查詢 2.explain 你的 select 查詢 3.當只要一行資料時使用 limit 1 4.為搜尋欄位建索引 5.千萬不要 order by rand 6.避免 select 7.永遠為兩張表設定乙個 id 8.盡可能的使用 not null 9.把 ip 位址存成 unsi...
資料庫伺服器優化思路
在大資料 大訪問量的時代，資料庫的效能優化無疑是非常重要的，下面總結了一些優化思路。1.應該先從巨集觀架構角度考慮，先通過觀察或指令碼，確定資料庫效能問題是否是週期性的波動。如果是週期性的，一般是訪問高峰或快取雪崩造成的。可以通過增加快取或更改快取失效策略，使失效時間分散或夜間訪問量低時定時失效。關...
針對Mysql資料庫伺服器的優化
mysql 資料庫的優化 最近一直在搞mysql資料庫的配置和優化，下面記錄一下這些天研究的結果，以方便以後檢視。一 伺服器的硬體的優化 對mysql伺服器來說主要從以下幾個方面來考慮 1 磁碟尋道能力 磁碟i o 因為mysql每一秒都在進行著大量的 複雜的查詢操作，對磁碟的讀寫可想而知，所以通常...