Mysql數據庫優化方法小結

對於有經驗pr來講Mysql數據庫的優化最基本了幾點就是,索引,主鍵,表結構，sql優化等下面小編來給大家總結一下。

一、數據庫設計

　　適度的反范式,注意是適度的

　　我們都知道三范式，基於三范式建立的模型是最有效保存數 據的方式，也是最容易擴展的模式。我們在開發應用程序時，設計的數據庫要最大程度的遵守三范式，特別是對於OLTP型的系統，三范式是必須遵守的規則。當 然，三范式最大的問題在於查詢時通常需要join很多表，導致查詢效率很低。所以有時候基於性能考慮，我們需要有意的違反三范式，適度的做冗余，以達到提 高查詢效率的目的。注意這裡的反范式是適度的，必須為這種做法提供充分的理由。下面就是一個糟糕的實例：　　

　 　在這裡，為了提高學生活動記錄的檢索效率，把單位名稱冗余到學生活動記錄表裡。單位信息有500條記錄，而學生活動記錄在一年內大概有200萬數據量。 如果學生活動記錄表不冗余這個單位名稱字段，只包含三個int字段和一個timestamp字段，只占用了16字節，是一個很小的表。而冗余了一個 varchar(32)的字段後則是原來的3倍，檢索起來相應也多了這麼多的I/O。而且記錄數相差懸殊，500 VS 2000000 ，導致更新一個單位名稱還要更新4000條冗余記錄。由此可見，這個冗余根本就是適得其反。

　　下面這個冗余就很好　　

　 　可以看到，[學生考試總分]是冗余的，這個分數完全可以通過[得分情況]匯總得到。在【學生考試總分】裡，一次考試一個學生只有一條記錄，而在【得分情 況】裡，一個學生針對試卷裡一個小題的一個小問一條記錄，粗略的算一下比例大概是1：100。而且判卷子得分是不會輕易變的，更新的頻率不高，所以說這個 冗余是比較好的。

適當建立索引

1，創建索引

對於查詢占主要的應用來說，索引顯得尤為重要。很多時候性能問題很簡單的就是因為我們忘了添加索引而造成的，或者說沒有添加更為有效的索引導致。如果不加索引的話，那麼查找任何哪怕只是一條特定的數據都會進行一次全表掃描，如果一張表的數據量很大而符合條件的結果又很少，那麼不加索引會引起致命的性能下降。但是也不是什麼情況都非得建索引不可，比如性別可能就只有兩個值，建索引不僅沒什麼優勢，還會影響到更新速度，這被稱為過度索引。
2，復合索引

比如有一條語句是這樣的：select * from users where area=’beijing’ and age=22;
如果我們是在area和age上分別創建單個索引的話，由於mysql查詢每次只能使用一個索引，所以雖然這樣已經相對不做索引時全表掃描提高了很多效率，但是如果在area、age兩列上創建復合索引的話將帶來更高的效率。如果我們創建了(area, age, salary)的復合索引，那麼其實相當於創建了(area,age,salary)、(area,age)、(area)三個索引，這被稱為最佳左前綴特性。因此我們在創建復合索引時應該將最常用作限制條件的列放在最左邊，依次遞減。
3，索引不會包含有NULL值的列

只要列中包含有NULL值都將不會被包含在索引中，復合索引中只要有一列含有NULL值，那麼這一列對於此復合索引就是無效的。所以我們在數據庫設計時不要讓字段的默認值為NULL。
4，使用短索引

對串列進行索引，如果可能應該指定一個前綴長度。例如，如果有一個CHAR(255)的 列，如果在前10 個或20 個字符內，多數值是惟一的，那麼就不要對整個列進行索引。短索引不僅可以提高查詢速度而且可以節省磁盤空間和I/O操作。
5，排序的索引問題

mysql查詢只使用一個索引，因此如果where子句中已經使用了索引的話，那麼order by中的列是不會使用索引的。因此數據庫默認排序可以符合要求的情況下不要使用排序操作；盡量不要包含多個列的排序，如果需要最好給這些列創建復合索引。
6，like語句操作

一般情況下不鼓勵使用like操作，如果非使用不可，如何使用也是一個問題。like “%aaa%” 不會使用索引而like “aaa%”可以使用索引。

7，不要在列上進行運算

select * from users where YEAR(adddate)<2007;
將在每個行上進行運算，這將導致索引失效而進行全表掃描，因此我們可以改成
select * from users where adddate<‘2007-01-01’;

8，不使用NOT IN和<>操作

NOT IN和<>操作都不會使用索引將進行全表掃描。NOT IN可以NOT EXISTS代替，id<>3則可使用id>3 or id<3來代替。