聚集索引以及非聚集索引用的是b+樹索引。
聚簇索引
單單從定義來看是不是顯得有點抽象，打個比方，乙個表就像是我們以前用的新華字典，聚集索引就像是拼音目錄，而每個字存放的頁碼就是我們的資料實體地址。
非聚集索引
其實按照定義，除了聚集索引以外的索引都是非聚集索引，只是人們想細分一下非聚集索引，分成普通索引，唯一索引，全文索引。如果非要把非聚集索引模擬成現實生活中的東西，那麼非聚集索引就像新華字典的偏旁字典，他結構順序與實際存放順序不一定一致。
資料庫中索引的優缺點
為什麼要建立索引呢？
這是因為，建立索引可以大大提高系統的效能。
第一，通過建立唯一性索引，可以保證資料庫表中每一行資料的唯一性。
第二，可以大大加快資料的檢索速度，這也是建立索引的最主要的原因。
第三，可以加速表和表之間的連線，特別是在實現資料的參考完整性方面特別有意義。
第四，在使用分組和排序子句進行資料檢索時，同樣可以顯著減少查詢中分組和排序的時間。
第五，通過使用索引，可以在查詢的過程中，使用優化隱藏器，提高系統的效能。
(一)深入淺出理解索引結構
實際上，您可以把索引理解為一種特殊的目錄。微軟的sql server提供了兩種索引：聚集索引(clustered index，也稱聚類索引、簇集索引)和非聚集索引(nonclustered index，也稱非聚類索引、非簇集索引)。下面，我們舉例來說明一下聚集索引和非聚集索引的區別：
其實，我們的漢語字典的正文本身就是乙個聚集索引。比如，我們要查「安」字，就會很自然地翻開字典的前幾頁，因為「安」的拼音是「an」，而按照拼音排序漢字的字典是以英文本母「a」開頭並以「z」結尾的，那麼「安」字就自然地排在字典的前部。如果您翻完了所有以「a」開頭的部分仍然找不到這個字，那麼就說明您的字典中沒有這個字；同樣的，如果查「張」字，那您也會將您的字典翻到最後部分，因為「張」的拼音是「zhang」。也就是說，字典的正文部分本身就是乙個目錄，您不需要再去查其他目錄來找到您需要找的內容。我們把這種正文內容本身就是一種按照一定規則排列的目錄稱為「聚集索引」。
如果您認識某個字，您可以快速地從自動中查到這個字。但您也可能會遇到您不認識的字，不知道它的發音，這時候，您就不能按照剛才的方法找到您要查的字，而需要去根據「偏旁部首」查到您要找的字，然後根據這個字後的頁碼直接翻到某頁來找到您要找的字。但您結合「部首目錄」和「檢字表」而查到的字的排序並不是真正的正文的排序方法，比如您查「張」字，我們可以看到在查部首之後的檢字表中「張」的頁碼是672頁，檢字表中「張」的上面是「馳」字，但頁碼卻是63頁，「張」的下面是「弩」字，頁面是390頁。很顯然，這些字並不是真正的分別位於「張」字的上下方，現在您看到的連續的「馳、張、弩」三字實際上就是他們在非聚集索引中的排序，是字典正文中的字在非聚集索引中的對映。我們可以通過這種方式來找到您所需要的字，但它需要兩個過程，先找到目錄中的結果，然後再翻到您所需要的頁碼。我們把這種目錄純粹是目錄，正文純粹是正文的排序方式稱為「非聚集索引」。
通過以上例子，我們可以理解到什麼是「聚集索引」和「非聚集索引」。進一步引申一下，我們可以很容易的理解：每個表只能有乙個聚集索引，因為目錄只能按照一種方法進行排序。
二、何時使用聚集索引或非聚集索引
事實上，我們可以通過前面聚集索引和非聚集索引的定義的例子來理解上表。如：返回某範圍內的資料一項。比如您的某個表有乙個時間列，恰好您把聚合索引建立在了該列，這時您查詢2023年1月1日至2023年10月1日之間的全部資料時，這個速度就將是很快的，因為您的這本字典正文是按日期進行排序的，聚類索引只需要找到要檢索的所有資料中的開頭和結尾資料即可；而不像非聚集索引，必須先查到目錄中查到每一項資料對應的頁碼，然後再根據頁碼查到具體內容。
三、結合實際，談索引使用的誤區
理論的目的是應用。雖然我們剛才列出了何時應使用聚集索引或非聚集索引，但在實踐中以上規則卻很容易被忽視或不能根據實際情況進行綜合分析。下面我們將根據在實踐中遇到的實際問題來談一下索引使用的誤區，以便於大家掌握索引建立的方法。
1、主鍵就是聚集索引
這種想法筆者認為是極端錯誤的，是對聚集索引的一種浪費。雖然sql server預設是在主鍵上建立聚集索引的。
通常，我們會在每個表中都建立乙個id列，以區分每條資料，並且這個id列是自動增大的，步長一般為1。我們的這個辦公自動化的例項中的列gid就是如此。此時，如果我們將這個列設為主鍵，sql server會將此列缺省為聚集索引。這樣做有好處，就是可以讓您的資料在資料庫中按照id進行物理排序，但筆者認為這樣做意義不大。
顯而易見，聚集索引的優勢是很明顯的，而每個表中只能有乙個聚集索引的規則，這使得聚集索引變得更加珍貴。
從我們前面談到的聚集索引的定義我們可以看出，使用聚集索引的最大好處就是能夠根據查詢要求，迅速縮小查詢範圍，避免全表掃瞄。在實際應用中，因為id號是自動生成的，我們並不知道每條記錄的id號，所以我們很難在實踐中用id號來進行查詢。這就使讓id號這個主鍵作為聚集索引成為一種資源浪費。其次，讓每個id號都不同的字段作為聚集索引也不符合「大數目的不同值情況下不應建立聚合索引」規則；當然，這種情況只是針對使用者經常修改記錄內容，特別是索引項的時候會負作用，但對於查詢速度並沒有影響。
在辦公自動化系統中，無論是系統首頁顯示的需要使用者簽收的檔案、會議還是使用者進行檔案查詢等任何情況下進行資料查詢都離不開欄位的是「日期」還有使用者本身的「使用者名稱」。
通常，辦公自動化的首頁會顯示每個使用者尚未簽收的檔案或會議。雖然我們的where語句可以僅僅限制當前使用者尚未簽收的情況，但如果您的系統已建立了很長時間，並且資料量很大，那麼，每次每個使用者開啟首頁的時候都進行一次全表掃瞄，這樣做意義是不大的，絕大多數的使用者1個月前的檔案都已經瀏覽過了，這樣做只能徒增資料庫的開銷而已。事實上，我們完全可以讓使用者開啟系統首頁時，資料庫僅僅查詢這個使用者近3個月來未閱覽的檔案，通過「日期」這個欄位來限制表掃瞄，提高查詢速度。如果您的辦公自動化系統已經建立的2年，那麼您的首頁顯示速度理論上將是原來速度8倍，甚至更快。
在這裡之所以提到「理論上」三字，是因為如果您的聚集索引還是盲目地建在id這個主鍵上時，您的查詢速度是沒有這麼高的，即使您在「日期」這個欄位上建立的索引(非聚合索引)。
五、其他注意事項
「水可載舟，亦可覆舟」，索引也一樣。索引有助於提高檢索效能，但過多或不當的索引也會導致系統低效。因為使用者在表中每加進乙個索引，資料庫就要做更多的工作。過多的索引甚至會導致索引碎片。
所以說，我們要建立乙個「適當」的索引體系，特別是對聚合索引的建立，更應精益求精，以使您的資料庫能得到高效能的發揮。
當然，在實踐中，作為乙個盡職的資料庫管理員，您還要多測試一些方案，找出哪種方案效率最高、最為有效。
有索引情況下，insert速度一定有影響，不過：1. 你不大可能一該不停地進行insert, sql server能把你傳來的命令快取起來，依次執行，不會漏掉任何乙個insert。2. 你也可以建立乙個相同結構但不做索引的表，insert資料先插入到這個表裡，當這個表中行數達到一定行數再用insert table1 select * from table2這樣的命令整批插入到有索引的那個表裡。
innodb儲存引擎支援以下幾種常見的索引：
b+樹索引
就是傳統意義上的索引，b+樹索引的構造類似於二叉樹，根據鍵值快速找到資料。b+樹索引並不能找到乙個給定鍵值的具體行。b+樹索引能找到的只是被查詢資料行所在的頁。然後資料庫通過把頁讀入到記憶體，再在記憶體中進行查詢，最後得到要查詢的資料。
全文索引
通過數值比較、範圍過濾就可以完成絕大多數我們需要的查詢了。但是，如果你希望通過關鍵字的匹配來進行查詢過濾，那麼就需要基於相似度的查詢，而不是原來的精確數值比較。全文索引就是為這種場景設計的。
雜湊索引
innodb儲存引擎支援的雜湊索引是自適應的，innodb儲存引擎會根據表的使用情況自動為表生成雜湊索引，不能人為干預是否在一張表中生成雜湊索引。
mysql 鍵值型別
普通索引 index (id name *** age loves)
唯一索引 unique
主鍵 primary key
外來鍵 foreign key
全文索引 fulltext
mysql 雜湊索引 MySQL索引之雜湊索引
雜湊索引 hash index 建立在雜湊表的基礎上，它只對使用了索引中的每一列的精確查詢有用。對於每一行，儲存引擎計算出了被索引的雜湊碼 hash code 它是乙個較小的值，並且有可能和其他行的雜湊碼不同。它把雜湊碼儲存在索引中，並且儲存了乙個指向雜湊表中的每一行的指標。在mysql中，只有me...
mysql主鍵索引 MySQL索引之主鍵索引
在mysql裡，主鍵索引和輔助索引分別是什麼意思，有什麼區別？上次的分享我們介紹了聚集索引和非聚集索引的區別，本次我們繼續介紹主鍵索引和輔助索引的區別。1 主鍵索引 主鍵索引，簡稱主鍵，原文是primary key，由乙個或多個列組成，用於唯一性標識資料表中的某一條記錄。乙個表可以沒有主鍵，但最多只...
mysql聚集索引 MySQL索引之聚集索引介紹
在mysql裡，聚集索引和非聚集索引分別是什麼意思，有什麼區別?在mysql中，innodb引擎表是 聚集 索引組織表 clustered index organize table 而myisam引擎表則是堆組織表 heap organize table 也有人把聚集索引稱為聚簇索引。當然了，聚集索...