• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            牽著老婆滿街逛

            嚴以律己,寬以待人. 三思而后行.
            GMail/GTalk: yanglinbo#google.com;
            MSN/Email: tx7do#yahoo.com.cn;
            QQ: 3 0 3 3 9 6 9 2 0 .

            聚集索引和非聚集索引的區別

            轉載自:http://www.cnblogs.com/flashicp/archive/2007/05/08/739245.html


            聚集索引非聚集索引的區別:
                   漢語字典的正文本身就是一個聚集索引。比如,我們要查“安”字,就會很自然地翻開字典的前幾頁,因為“安”的拼音是“an”,而按照拼音排序漢字的字典是以英文字母“a”開頭并以“z”結尾的,那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”開頭的部分仍然找不到這個字,那么就說明您的字典中沒有這個字;同樣的,如果查“張”字,那您也會將您的字典翻到最后部分,因為“張”的拼音是“zhang”。也就是說,字典的正文部分本身就是一個目錄,您不需要再去查其他目錄來找到您需要找的內容。正文內容本身就是一種按照一定規則排列的目錄稱為“聚集索引”。
                如果您認識某個字,您可以快速地從自動中查到這個字。但您也可能會遇到您不認識的字,不知道它的發音,這時候,您就不能按照剛才的方法找到您要查的字,而需要去根據“偏旁部首”查到您要找的字,然后根據這個字后的頁碼直接翻到某頁來找到您要找的字。但您結合“部首目錄”和“檢字表”而查到的字的排序并不是真正的正文的排序方法,比如您查“張”字,我們可以看到在查部首之后的檢字表中“張”的頁碼是672頁,檢字表中“張”的上面是“馳”字,但頁碼卻是63頁,“張”的下面是“弩”字,頁面是390頁。很顯然,這些字并不是真正的分別位于“張”字的上下方,現在您看到的連續的“馳、張、弩”三字實際上就是他們在非聚集索引中的排序,是字典正文中的字在非聚集索引中的映射。我們可以通過這種方式來找到您所需要的字,但它需要兩個過程,先找到目錄中的結果,然后再翻到您所需要的頁碼。

            我們把這種目錄純粹是目錄,正文純粹是正文的排序方式稱為“非聚集索引”。

            通過以上例子,我們可以理解到什么是“聚集索引”和“非聚集索引”。

            進一步引申一下,我們可以很容易的理解:每個表只能有一個聚集索引,因為目錄只能按照一種方法進行排序。
            得出查詢速度的方法是:在各個select語句前加:
            declare @d datetime
            set @d=getdate()
            并在select語句后加:
            select [語句執行花費時間(毫秒)]=datediff(ms,@d,getdate())

            1、用聚合索引比用不是聚合索引的主鍵速度快;
            2、用聚合索引比用一般的主鍵作order by時速度快,特別是在小數據量情況下。
                  事實上,如果數據量很小的話,用聚集索引作為排序列要比使用非聚集索引速度快得明顯的多;而數據量如果很大的話,如10萬以上,則二者的速度差別不明顯。
            3、使用聚合索引內的時間段,搜索時間會按數據占整個數據表的百分比成比例減少,而無論聚合索引使用了多少個;
            4 、日期列不會因為有分秒的輸入而減慢查詢速度。

            從publish 表中取出第 n 條到第 m 條的記錄: 
            SELECT TOP m-n+1 * 
            FROM publish 
            WHERE (id NOT IN 
                (
            SELECT TOP n-1 id 
                 
            FROM publish)) 
            id 為publish 表的關鍵字 

            只所以把“查詢優化”和“分頁算法”這兩個聯系不是很大的論題放在一起,就是因為二者都需要一個非常重要的東西――聚集索引。

            在前面的討論中我們已經提到了,聚集索引有兩個最大的優勢:
            1、以最快的速度縮小查詢范圍;
            2、以最快的速度進行字段排序。

            第1條多用在查詢優化時,而第2條多用在進行分頁時的數據排序。
                  而聚集索引在每個表內又只能建立一個,這使得聚集索引顯得更加的重要。聚集索引的挑選可以說是實現“查詢優化”和“高效分頁”的最關鍵因素。
                  但要既使聚集索引列既符合查詢列的需要,又符合排序列的需要,這通常是一個矛盾。

            聚集索引是如此的重要和珍貴,所以一定要將聚集索引建立在:
            1、您最頻繁使用的、用以縮小查詢范圍的字段上;
            2、您最頻繁使用的、需要排序的字段上。

            posted on 2011-03-31 16:26 楊粼波 閱讀(637) 評論(0)  編輯 收藏 引用

            国内精品久久久久久久coent | 久久久久国产成人精品亚洲午夜| 99久久这里只有精品| 91性高湖久久久久| 亚洲成av人片不卡无码久久| 久久久久亚洲av成人网人人软件 | 国产精品禁18久久久夂久| 麻豆精品久久久一区二区| 亚洲欧美日韩久久精品| 久久人妻少妇嫩草AV无码专区| 老司机国内精品久久久久| 欧美激情一区二区久久久| 无码AV中文字幕久久专区| 99久久香蕉国产线看观香| 国产毛片欧美毛片久久久| 精品久久久久中文字幕日本| 久久久久国产亚洲AV麻豆| 亚洲AV成人无码久久精品老人| 久久99精品国产麻豆不卡| 欧美黑人激情性久久| 国产精品成人久久久| 国产精品久久久久乳精品爆| 无码人妻少妇久久中文字幕蜜桃| 色偷偷91久久综合噜噜噜噜| 久久九九青青国产精品| 亚洲av日韩精品久久久久久a| 亚洲成av人片不卡无码久久| 99久久精品免费观看国产| 国内精品久久久久影院优| 亚洲va国产va天堂va久久| 久久久久久久波多野结衣高潮 | 色综合久久中文字幕综合网| 2021久久精品国产99国产精品| 精品国产乱码久久久久久人妻| 伊人久久大香线蕉精品不卡| 欧美成a人片免费看久久| 久久久久九国产精品| 久久青青草原精品国产软件 | 韩国三级大全久久网站| 久久国产精品99国产精| 国产亚洲精久久久久久无码|