在這里之所以提到“理論上”三字，是因?yàn)槿绻木奂饕€是盲目地建在ID這個(gè)主鍵上時(shí)，您的查詢速度是沒有這么高的，即使您在“日期”這個(gè)字段上建立的索引（非聚合索引）。下面我們就來看一下在1000萬條數(shù)據(jù)量的情況下各種查詢的速度表現(xiàn)（3個(gè)月內(nèi)的數(shù)據(jù)為25萬條）：

（1）僅在主鍵上建立聚集索引，并且不劃分時(shí)間段：

用時(shí)：128470毫秒（即：128秒）

（2）在主鍵上建立聚集索引，在fariq上建立非聚集索引：

用時(shí)：53763毫秒（54秒）

（3）將聚合索引建立在日期列（fariqi）上：

用時(shí)：2423毫秒（2秒）

　　雖然每條語句提取出來的都是25萬條數(shù)據(jù)，各種情況的差異卻是巨大的，特別是將聚集索引建立在日期列時(shí)的差異。事實(shí)上，如果您的數(shù)據(jù)庫真的有1000萬容量的話，把主鍵建立在ID列上，就像以上的第1、2種情況，在網(wǎng)頁上的表現(xiàn)就是超時(shí)，根本就無法顯示。這也是我摒棄ID列作為聚集索引的一個(gè)最重要的因素。得出以上速度的方法是：在各個(gè)select語句前加：

并在select語句后加：

2、只要建立索引就能顯著提高查詢速度
　　事實(shí)上，我們可以發(fā)現(xiàn)上面的例子中，第2、3條語句完全相同，且建立索引的字段也相同；不同的僅是前者在fariqi字段上建立的是非聚合索引，后者在此字段上建立的是聚合索引，但查詢速度卻有著天壤之別。所以，并非是在任何字段上簡單地建立索引就能提高查詢速度。

　　從建表的語句中，我們可以看到這個(gè)有著1000萬數(shù)據(jù)的表中fariqi字段有5003個(gè)不同記錄。在此字段上建立聚合索引是再合適不過了。在現(xiàn)實(shí)中，我們每天都會發(fā)幾個(gè)文件，這幾個(gè)文件的發(fā)文日期就相同，這完全符合建立聚集索引要求的：“既不能絕大多數(shù)都相同，又不能只有極少數(shù)相同”的規(guī)則。由此看來，我們建立“適當(dāng)”的聚合索引對于我們提高查詢速度是非常重要的。

3、把所有需要提高查詢速度的字段都加進(jìn)聚集索引，以提高查詢速度
　　上面已經(jīng)談到：在進(jìn)行數(shù)據(jù)查詢時(shí)都離不開字段的是“日期”還有用戶本身的“用戶名”。既然這兩個(gè)字段都是如此的重要，我們可以把他們合并起來，建立一個(gè)復(fù)合索引（compound index）。

　　很多人認(rèn)為只要把任何字段加進(jìn)聚集索引，就能提高查詢速度，也有人感到迷惑：如果把復(fù)合的聚集索引字段分開查詢，那么查詢速度會減慢嗎？帶著這個(gè)問題，我們來看一下以下的查詢速度（結(jié)果集都是25萬條數(shù)據(jù)）：（日期列fariqi首先排在復(fù)合聚集索引的起始列，用戶名neibuyonghu排在后列）：

查詢速度：2513毫秒


查詢速度：2516毫秒


查詢速度：60280毫秒

　　從以上試驗(yàn)中，我們可以看到如果僅用聚集索引的起始列作為查詢條件和同時(shí)用到復(fù)合聚集索引的全部列的查詢速度是幾乎一樣的，甚至比用上全部的復(fù)合索引列還要略快（在查詢結(jié)果集數(shù)目一樣的情況下）；而如果僅用復(fù)合聚集索引的非起始列作為查詢條件的話，這個(gè)索引是不起任何作用的。當(dāng)然，語句1、2的查詢速度一樣是因?yàn)椴樵兊臈l目數(shù)一樣，如果復(fù)合索引的所有列都用上，而且查詢結(jié)果少的話，這樣就會形成“索引覆蓋”，因而性能可以達(dá)到最優(yōu)。同時(shí)，請記?。簾o論您是否經(jīng)常使用聚合索引的其他列，但其前導(dǎo)列一定要是使用最頻繁的列。

最新評論