對(duì)于一個(gè)以數(shù)據(jù)為中心的應(yīng)用，數(shù)據(jù)庫(kù)的好壞直接影響到程序的性能，因此數(shù)據(jù)庫(kù)性能至關(guān)重要。一般來(lái)說(shuō)，要保證數(shù)據(jù)庫(kù)的效率，要做好以下四個(gè)方面的工作：數(shù)據(jù)庫(kù)設(shè)計(jì)、sql語(yǔ)句優(yōu)化、數(shù)據(jù)庫(kù)參數(shù)配置、恰當(dāng)?shù)挠布Y源和操作系統(tǒng)，這個(gè)順序也表現(xiàn)了這四個(gè)工作對(duì)性能影響的大小。下面我們逐個(gè)闡明：
一、數(shù)據(jù)庫(kù)設(shè)計(jì)
適度的反范式，注意是適度的
我們都知道三范式，基于三范式建立的模型是最有效保存數(shù) 據(jù)的方式，也是最容易擴(kuò)展的模式。我們?cè)陂_發(fā)應(yīng)用程序時(shí)，設(shè)計(jì)的數(shù)據(jù)庫(kù)要最大程度的遵守三范式，特別是對(duì)于OLTP型的系統(tǒng)，三范式是必須遵守的規(guī)則。當(dāng) 然，三范式最大的問題在于查詢時(shí)通常需要join很多表，導(dǎo)致查詢效率很低。所以有時(shí)候基于性能考慮，我們需要有意的違反三范式，適度的做冗余，以達(dá)到提 高查詢效率的目的。注意這里的反范式是適度的，必須為這種做法提供充分的理由。下面就是一個(gè)糟糕的實(shí)例：
在這里，為了提高學(xué)生活動(dòng)記錄的檢索效率，把單位名稱冗余到學(xué)生活動(dòng)記錄表里。單位信息有500條記錄，而學(xué)生活動(dòng)記錄在一年內(nèi)大概有200萬(wàn)數(shù)據(jù)量。 如果學(xué)生活動(dòng)記錄表不冗余這個(gè)單位名稱字段，只包含三個(gè)int字段和一個(gè)timestamp字段，只占用了16字節(jié)，是一個(gè)很小的表。而冗余了一個(gè) varchar（32）的字段后則是原來(lái)的3倍，檢索起來(lái)相應(yīng)也多了這么多的I/O。而且記錄數(shù)相差懸殊，500 VS 2000000 ，導(dǎo)致更新一個(gè)單位名稱還要更新4000條冗余記錄。由此可見，這個(gè)冗余根本就是適得其反。
下面這個(gè)冗余就很好
可以看到，［學(xué)生考試總分］是冗余的，這個(gè)分?jǐn)?shù)完全可以通過(guò)［得分情況］匯總得到。在【學(xué)生考試總分】里，一次考試一個(gè)學(xué)生只有一條記錄，而在【得分情 況】里，一個(gè)學(xué)生針對(duì)試卷里一個(gè)小題的一個(gè)小問一條記錄，粗略的算一下比例大概是1：100。而且判卷子得分是不會(huì)輕易變的，更新的頻率不高，所以說(shuō)這個(gè) 冗余是比較好的。