4. 聚集索引和非聚集的區別
聚集索引和非聚集索引的根本區別是數據記錄的排列順序和索引的排列順序是否一致，聚集索引表記錄的排列順序與索引的排列順序一致，優點是查詢速度快，因爲一旦具有第一個索引值的紀錄被找到，具有連續索引值的記錄也一定物理的緊跟其後，從而縮小了搜索範圍，對於返回某一範圍的數據效果最好。
聚集索引的缺點是對錶進行修改速度較慢，這是爲了保持表中的記錄的物理順序與索引的順序一致，而把記錄插入到數據頁的相應位置，必須在數據頁中進行數據重排，降低了執行速度。
非聚集索引指定了表中記錄的邏輯順序，數據記錄的物理順序和索引的順序不一致，聚集索引和非聚集索引都採用了B樹的結構，但非聚集索引的葉子層順序並不與實際的數據頁相同，而採用指向表中的記錄在數據頁中位置的方式。非聚集索引比聚集索引層次多，添加記錄不會引起數據順序的重組。在有大量不同數據的列上建立非聚集索引，可以提高數據的查詢和修改速度。
在對聚集索引列查詢時，聚集索引的速度要比非聚集索引速度快。
在對聚集索引列排序時，聚集索引的速度要比非聚集索引速度快。但是如果數據量比較大時，如10萬以上，則二者的速度差別不明顯。
5. 聚集索引和非聚集的建立原則
在創建索引時要做到三個適當，即在適當的表上、適當的列上創建適當數量的索引。雖然這可以通過一句話來概括優化的索引的基本準則，但是要做到這一點的話，需要做出很大的努力。具體的來說，要做到這個三個適當有如下幾個要求。
5.1 根據表的大小來創建索引。
雖然給表創建索引，可以提高查詢的效率。但是需要注意的是，索引也需要一定的開銷的。爲此並不是說給所有的表都創建索引，那麼就可以提高數據庫的性能。這個認識是錯誤的。給所有的表都創建了索引，那麼其反而會給數據庫的性能造成負面的影響。因爲此時濫用索引的開銷可能已經遠遠大於由此帶來的性能方面的收益。所以，數據庫管理員首先需要做到，爲合適的表來建立索引，而不是爲所有的表建立索引。
一般來說，不需要爲比較小的表創建索引。因爲即使建立了索引，其性能也不會得到很大的改善。相反索引建立的開銷，如維護成本等等，要比這個要大。也就是說，付出的要比得到的多，顯然違反常理。
另外，就是對於超大的表，也不一定要建立索引。有些表雖然比較大，記錄數量非常的多。但是此時爲這個表建立索引並一定的合適。對於一些超大的表，建立索引有時候往往不能夠達到預計的效果。而且在大表上建立索引，其索引的開銷要比普通的表大的多。那麼到底是否給大表建立索引呢？主要是看兩個方面的內容。首先是需要關注一下，在這張大表中經常需要查詢的記錄數量。一般來說，如果經常需要查詢的數據不超過10%到15%的話，那就沒有必要爲其建立索引的必要。因爲此時建立索引的開銷可能要比性能的改善大的多。如果數據庫管理員需要得出一個比較精確的結論，那麼就需要進行測試分析。
5.2 根據列的特徵來創建索引
列的特點不同，索引創建的效果也不同。需要了解爲哪些列創建索引可以起到事半功倍的效果。同時也需要了解爲哪些列創建索引反而起到的是事倍功半的效果。
索引設置的是否恰當，不僅跟數據庫設計架構有關，而且還跟企業的經濟業務相關。雖然一開始已經做了索引的優化工作。但是隨着後來經濟數據的增加，這個索引的效果會越來越打折扣。所以需要隔一段時間，對數據庫的索引進行優化。該去掉的去掉，該調整的調整，以提高數據庫的性能。
5.3 在一個表上創建多少索引合適
通常來說，表的索引越多，其查詢的速度也就越快。但是，表的更新速度則會降低。這主要是因爲表的更新同時也是索引的更新。到底在表中創建多少索引合適，就需要在這個更新速度與查詢速度之間取得一個均衡點。如對於一些數據倉庫或者決策型數據庫系統，其主要用來進行查詢。相關的記錄往往是在數據庫初始化的時候導入。此時，設置的索引多一點，可以提高數據庫的查詢性能。同時因爲記錄不怎麼更新，所以索引比較多的情況下，也不會影響到更新的速度。相反，如果那些表中經常需要更新記錄，如一些事務型的應用系統，數據更新操作是家常便飯的事情。此時如果在一張表中建立過多的索引，則會影響到更新的速度。由於更新操作比較頻繁，所以對其的負面影響，要比查詢效率提升要大的多。此時就需要限制索引的數量，只在一些必要的字段上建立索引。
總之，在適當的表、適當的列上建立適當的索引。具體的索引優化內容還是需要在日常工作中繼續體會與總結。
下面的表總結了何時使用聚集索引或非聚集索引：
|
動作描述 |
使用聚集索引 |
使用非聚集索引 |
|
列經常被分組排序 |
應 |
應 |
|
返回某範圍內的數據 |
應 |
不應 |
|
一個或極少不同值 |
不應 |
不應 |
|
小數目的不同值 |
應 |
不應 |
|
大數目的不同值 |
不應 |
應 |
|
頻繁更新的列 |
不應 |
應 |
|
外鍵列 |
應 |
應 |
|
主鍵列 |
應 |
應 |
|
頻繁修改索引列 |
不應 |
應 |