❶ sql中一個表可以有幾個聚集索引或非聚集索引
一個表只能有一個聚集索引，可以有多個非聚集索引
下面是聚集索引和非聚集索引的詳細介紹：
聚集索引基於數據行的鍵值在表內排序和存儲這些數據行。每個表只能有一個聚集索引，因為數據行本身只能按一個順序存儲。有關聚集索引體系結構的詳細信息，請參閱聚集索引結構。
每個表幾乎都對列定義聚集索引來實現下列功能：
可用於經常使用的查詢。
提供高度唯一性。
注意：
創建 PRIMARY KEY 約束時，將在列上自動創建唯一索引。默認情況下，此索引是聚集索引，但是在創建約束時，可以指定創建非聚集索引。
可用於范圍查詢。
如果未使用 UNIQUE 屬性創建聚集索引，資料庫引擎將向表自動添加一個 4 位元組的 uniqueifier
列。必要時，資料庫引擎將向行自動添加一個 uniqueifier 值以使每個鍵唯一。此列和列值供內部使用，用戶不能查看或訪問。
查詢注意事項
在創建聚集索引之前，應先了解數據是如何被訪問的。考慮對具有以下特點的查詢使用聚集索引：
使用運算符（如 BETWEEN、>、>=、< 和
<=）返回一系列值。
使用聚集索引找到包含第一個值的行後，便可以確保包含後續索引值的行物理相鄰。例如，如果某個查詢在一系列銷售訂單號間檢索記錄，SalesOrderNumber
列的聚集索引可快速定位包含起始銷售訂單號的行，然後檢索表中所有連續的行，直到檢索到最後的銷售訂單號。
返回大型結果集。
使用 JOIN 子句；一般情況下，使用該子句的是外鍵列。
使用 ORDER BY 或 GROUP BY 子句。
在 ORDER BY 或 GROUP BY
子句中指定的列的索引，可以使資料庫引擎不必對數據進行排序，因為這些行已經排序。這樣可以提高查詢性能。
列注意事項
一般情況下，定義聚集索引鍵時使用的列越少越好。考慮具有下列一個或多個屬性的列：
唯一或包含許多不重復的值
例如，雇員 ID 唯一地標識雇員。EmployeeID 列的聚集索引或 PRIMARY KEY
約束將改善基於雇員 ID 號搜索雇員信息的查詢的性能。另外，可對
LastName、FirstName、MiddleName
列創建聚集索引，因為經常以這種方式分組和查詢雇員記錄，而且這些列的組合還可提供高區分度。
按順序被訪問
例如，產品 ID 唯一地標識 AdventureWorks2008R2 資料庫的
Proction.Proct 表中的產品。在其中指定順序搜索的查詢（如 WHERE ProctID BETWEEN 980
and 999）將從 ProctID 的聚集索引受益。這是因為行將按該鍵列的排序順序存儲。
由於保證了列在表中是唯一的，所以定義為 IDENTITY。
經常用於對表中檢索到的數據進行排序。
按該列對表進行聚集（即物理排序）是一個好方法，它可以在每次查詢該列時節省排序操作的成本。
聚集索引不適用於具有下列屬性的列：
頻繁更改的列
這將導致整行移動，因為資料庫引擎必須按物理順序保留行中的數據值。這一點要特別注意，因為在大容量事務處理系統中數據通常是可變的。
寬鍵
寬鍵是若干列或若干大型列的組合。所有非聚集索引將聚集索引中的鍵值用作查找鍵。為同一表定義的任何非聚集索引都將增大許多，這是因為非聚集索引項包含聚集鍵，同時也包含為此非聚集索引定義的鍵列。
索引選項
創建聚集索引時，可指定若干索引選項。因為聚集索引通常都很大，所以應特別注意下列選項：
SORT_IN_TEMPDB
DROP_EXISTING
FILLFACTOR
ONLINE
非聚集索引包含索引鍵值和指向表數據存儲位置的行定位器。有關非聚集索引體系結構的詳細信息，請參閱非聚集索引結構。
可以對表或索引視圖創建多個非聚集索引。通常，設計非聚集索引是為改善經常使用的、沒有建立聚集索引的查詢的性能。
與使用書中索引的方式相似，查詢優化器在搜索數據值時，先搜索非聚集索引以找到數據值在表中的位置，然後直接從該位置檢索數據。這使非聚集索引成為完全匹配查詢的最佳選擇，因為索引包含說明查詢所搜索的數據值在表中的精確位置的項。例如，為了從
Person.Person 表中查詢具有特定姓氏的人員，查詢優化器可能使用非聚集索引
IX_Person_LastName_FirstName_MiddleName；它以 LastName 作為自己的一個鍵列。查詢優化器能快速找出索引中與指定
LastName
匹配的所有項。每個索引項都指向表或聚集索引中准確的頁和行，其中可以找到相應的數據。在查詢優化器在索引中找到所有項之後，它可以直接轉到准確的頁和行進行數據檢索。
資料庫注意事項
設計非聚集索引時需要注意資料庫的特徵。
更新要求較低但包含大量數據的資料庫或表可以從許多非聚集索引中獲益從而改善查詢性能。與全表非聚集索引相比，考慮為定義完善的數據子集創建篩選索引可以提高查詢性能、降低索引存儲開銷並減少索引維護開銷。
決策支持系統應用程序和主要包含只讀數據的資料庫可以從許多非聚集索引中獲益。查詢優化器具有更多可供選擇的索引用來確定最快的訪問方法，並且資料庫的低更新特徵意味著索引維護不會降低性能。
聯機事務處理應用程序和包含大量更新表的資料庫應避免使用過多的索引。此外，索引應該是窄的，即列越少越好。
一個表如果建有大量索引會影響
INSERT、UPDATE、DELETE 和 MERGE
語句的性能，因為當表中的數據更改時，所有索引都須進行適當的調整。
查詢注意事項
在創建非聚集索引之前，應先了解訪問數據的方式。考慮對具有以下屬性的查詢使用非聚集索引：
使用 JOIN 或 GROUP BY
子句。
應為聯接和分組操作中所涉及的列創建多個非聚集索引，為任何外鍵列創建一個聚集索引。
不返回大型結果集的查詢。
創建篩選索引以覆蓋從大型表中返回定義完善的行子集的查詢。
包含經常包含在查詢的搜索條件（例如返回完全匹配的 WHERE 子句）中的列。
列注意事項
考慮具有以下一個或多個屬性的列：
覆蓋查詢。
當索引包含查詢中的所有列時，性能可以提升。查詢優化器可以找到索引內的所有列值；不會訪問表或聚集索引數據，這樣就減少了磁碟
I/O 操作。使用具有包含列的索引來添加覆蓋列，而不是創建寬索引鍵。有關詳細信息，請參閱
具有包含列的索引
。
如果表有聚集索引，則該聚集索引中定義的列將自動追加到表上每個非聚集索引的末端。這可以生成覆蓋查詢，而不用在非聚集索引定義中指定聚集索引列。例如，如果一個表在
C 列上有聚集索引，則 B 和 A 列的非聚集索引將具有其自己的鍵值列 B、A 和 C。
大量非重復值，如姓氏和名字的組合（前提是聚集索引被用於其他列）。
如果只有很少的非重復值，例如僅有 1 和
0，則大多數查詢將不使用索引，因為此時表掃描通常更有效。對於這種類型的數據，應考慮對僅出現在少數行中的非重復值創建篩選索引。例如，如果大部分值都是
0，則查詢優化器可以對包含 1 的數據行使用篩選查詢。
索引選項
在創建非聚集索引時，可以指定若干索引選項。要尤其注意以下選項：
FILLFACTOR
ONLINE
❷ SQL聚集索引和非聚集索引的區別
資料庫的索引，聽起來挺神秘的，仔細想想。這些索引，其實就是平時咱們查東西時候常用的兩種手段。無非就是為了提高我們找東西的效率而已。那麼我們平時又是怎麼查東西呢？
聚集索引：
聚集索引，來源於生活嘗試。這中索引可以說是按照數據的物理存儲進行劃分的。對於一堆記錄來說，使用聚集索引就是對這堆記錄 進行 堆劃分。即主要描述的是物理上的存儲。
舉個例子：
比如圖書館新進了一批書。那麼這些書需要放到圖書館內。書如何放呢？一般都有一個規則，雜志類的放到101房間，文學類的放到102房間，理工類的放到103房間等等。這些存儲的規則決定了每本書應該放到哪裡。而這個例子中聚集索引為書的類別。
正式因為這種存儲規則，才導致 聚集索引的唯一性。
誤區：
有的人認為，聚集索引的欄位是唯一的。這是因為sql server 中添加主鍵的時候，自動給主鍵所在的欄位生成一個聚集索引。所以人們會認為聚集索引所加的欄位是唯一的。
思考一下上面這個問題。雜志類的書放到101房間。那麼如果雜志類的書太多，一個101房間存放不下。那麼可能101，201兩個房間來存放雜志類的書籍。如果這樣分析的話，那麼一個雜志類對應多個房間。放到表存儲的話，那麼這個類別欄位 就不是唯一的了。
非聚集索引：
非聚集索引，也可以從生活中找到映射。非聚集索引強調的是邏輯分類。可以說是定義了一套存儲規則，而需要有一塊控制項來維護這個規則，這個被稱之為索引表。
繼續使用上述提到的例子：
同學如果想去圖書館找一本書，而不知道這本書在哪裡？那麼這個同學首先應該找的就是 檢索室吧。對於要查找一本書來說，在檢索室查是一個非常快捷的的途徑了吧。但是，在檢索室中你查到了該書在XX室XX書架的信息。你的查詢結束了嗎？沒有吧。你僅僅找到了目的書的位置信息，你還要去該位置去取書。
對於這種方式來說，你需要兩個步驟：
1、查詢該記錄所在的位置。
2、通過該位置去取要找的記錄。
區別：
聚集索引：可以幫助把很大的范圍，迅速減小范圍。但是查找該記錄，就要從這個小范圍中Scan了。
非聚集索引：把一個很大的范圍，轉換成一個小的地圖。你需要在這個小地圖中找你要尋找的信息的位置。然後通過這個位置，再去找你所需要的記錄。
索引與主鍵的區別
主鍵：主鍵是唯一的，用於快速定位一條記錄。
聚集索引：聚集索引也是唯一的。（因為聚集索引的劃分依據是物理存儲）。而聚集索引的主要是為了快速的縮小查找范圍，即記錄數目未定。
主鍵和索引沒有關系。他們的用途相近。如果聚集索引加上唯一性約束之後，他們的作用就一樣了。
使用場景
基於上述的兩種規則，那麼在什麼時候適合聚集索引，什麼時候適合非聚集索引？
❸ SQL Server 聚集索引和非聚集索引的區別分析
聚集索引和非聚集索引的根本區別
聚集索引和非聚集索引的根本區別是表記錄的排列順序和與索引的排列順序是否一致，聚集索引表記錄的排列順序與索引的排列順序一致，優點是查詢速度快，因為一旦具有第一個索引值的紀錄被找到，具有連續索引值的記錄也一定物理的緊跟其後。
聚集索引的缺點是對表進行修改速度較慢，這是為了保持表中的記錄的物理順序與索引的順序一致，而把記錄插入到數據頁的相應位置，必須在數據頁中進行數據重排，降低了執行速度。建議使用聚集索引的場合為：
a.此列包含有限數目的不同值；
b.查詢的結果返回一個區間的值；
c.查詢的結果返回某值相同的大量結果集。
非聚集索引指定了表中記錄的邏輯順序，但記錄的物理順序和索引的順序不一致，聚集索引和非聚集索引都採用了B+樹的結構，但非聚集索引的葉子層並不與實際的數據頁相重疊，而採用葉子層包含一個指向表中的記錄在數據頁中的指針的方式。非聚集索引比聚集索引層次多，添加記錄不會引起數據順序的重組。建議使用非聚集索引的場合為：
a.此列包含了大量數目不同的值；
b.查詢的結束返回的是少量的結果集；
c.order by 子句中使用了該列。
--不用索引查詢
Select * FROM IndexTestTable WHIT(INDEX(0)) Where Status='B'
--創建聚集索引
Create CLUSTERED INDEX icIndexTestTable ON IndexTestTable(Status)
--使用索引查詢
Select * FROM IndexTestTable WITH(INDEX(icIndexTestTable)) Where Status='B'
表中經常有一個列或列的組合，其值能唯一地標識表中的每一行。這樣的一列或多列稱為表的主鍵(默認為聚集索引)。聚集索引確定表中數據的物理順序。聚集索引類似於電話簿，後者按姓氏排列數據。由於聚集索引規定數據在表中的物理存儲順序，因此一個表只能包含一個聚集索引。但該索引可以包含多個列（組合索引），就像電話簿按姓氏和名字進行組織一樣。
非聚集索引與課本中的索引類似。數據存儲在一個地方，索引存儲在另一個地方，索引帶有指針指向數據的存儲位置。索引中的項目按索引鍵值的順序存儲，而表中的信息按另一種順序存儲（這可以由聚集索引規定）。如果在表中未創建聚集索引，則無法保證這些行具有任何特定的順序。
聚集索引就像我們新華字典中的按拼音排序，即你查"愛"字可以在前面看到"癌"字，但卻不能在前後頁中看到"受"字。而非聚集索引就是新華字典中的按部首、筆劃排序。聚集索引相當於我們書本上前面的目錄的一樣，它可以方便快速的找到你想找的內容，而非聚集索引就相當於書最後幾頁的解釋，它是對書中某個語句或者是生詞的解釋，就像我們上學時候的地理說一樣，書後面都有各種地理名稱的英文解釋。
《資料庫原理》裡面的解釋：聚集索引的順序就是數據的物理存儲順序，而非聚集索引的順序和數據物理排列無關。因為數據在物理存放時只能有一種排列方式，所以一個表只能有一個聚集索引。
在SQL SERVER中，索引是通過二叉樹的數據結構來描述的；我們可以如此理解這個兩種索引：聚集索引的葉節點就是數據節點，而非聚集索引的葉節點仍然是索引節點，只不過其包含一個指向對應數據塊的指針。
聚集索引會降低 insert，和update操作的性能，所以，是否使用聚集索引要全面衡量。
❹ 聚簇索引與非聚簇索引（也叫二級索引）
澄清一個概念：innodb中，在聚簇索引之上創建的索引稱之為輔助索引，輔助索引訪問數據總是需要二次查找，非聚簇索引都是輔助索引，像復合索引、前綴索引、唯一索引，輔助索引葉子節點存儲的不再是行的物理位置，而是主鍵值
由於聚簇索引是將數據跟索引結構放到一塊，因此一個表僅有一個聚簇索引
聚簇索引默認是主鍵 ，如果表中沒有定義主鍵，InnoDB 會選擇一個 唯一的非空索引 代替。如果沒有這樣的索引，InnoDB 會 隱式定義一個主鍵 來作為聚簇索引。InnoDB 只聚集在同一個頁面中的記錄。包含相鄰健值的頁面可能相距甚遠。 如果你已經設置了主鍵為聚簇索引，必須先刪除主鍵，然後添加我們想要的聚簇索引，最後恢復設置主鍵即可 。
此時其他索引只能被定義為非聚簇索引。這個是最大的誤區。有的主鍵還是無意義的自動增量欄位，那樣的話Clustered index對效率的幫助，完全被浪費了。
剛才說到了，聚簇索引性能最好而且具有唯一性，所以非常珍貴，必須慎重設置。 一般要根據這個表最常用的SQL查詢方式來進行選擇，某個欄位作為聚簇索引，或組合聚簇索引 ，這個要看實際情況。
記住我們的 最終目的 就是 在相同結果集情況下，盡可能減少邏輯IO 。
MyISM使用的是非聚簇索引， 非聚簇索引的兩棵B+樹看上去沒什麼不同 ，節點的結構完全一致只是存儲的內容不同而已，主鍵索引B+樹的節點存儲了主鍵，輔助鍵索引B+樹存儲了輔助鍵。表數據存儲在獨立的地方，這兩顆B+樹的葉子節點都使用一個地址指向真正的表數據，對於表數據來說，這兩個鍵沒有任何差別。由於 索引樹是獨立的，通過輔助鍵檢索無需訪問主鍵的索引樹 。
看上去聚簇索引的效率明顯要低於非聚簇索引，因為 每次使用輔助索引檢索都要經過兩次B+樹查找 ，這不是多此一舉嗎？聚簇索引的優勢在哪？
所以建議使用int的auto_increment作為主鍵
主鍵的值是順序的，所以 InnoDB 把每一條記錄都存儲在上一條記錄的後面。當達到頁的最大填充因子時（InnoDB 默認的最大填充因子是頁大小的 15/16，留出部分空間用於以後修改），下一條記錄就會寫入新的頁中。一旦數據按照這種順序的方式載入，主鍵頁就會近似於被順序的記錄填滿（二級索引頁可能是不一樣的）
聚簇索引的數據的物理存放順序與索引順序是一致的 ，即： 只要索引是相鄰的，那麼對應的數據一定也是相鄰地存放在磁碟上的 。如果主鍵不是自增id，那麼可以想 象，它會幹些什麼，不斷地調整數據的物理地址、分頁，當然也有其他一些措施來減少這些操作，但卻無法徹底避免。但，如果是自增的，那就簡單了，它只需要一 頁一頁地寫，索引結構相對緊湊，磁碟碎片少，效率也高。
因為 MyISAM的主索引並非聚簇索引，那麼他的數據的物理地址必然是凌亂的，拿到這些物理地址，按照合適的演算法進行I/O讀取，於是開始不停的尋道不停的旋轉 。 聚簇索引則只需一次I/O 。（強烈的對比）
不過，如果 涉及到大數據量的排序、全表掃描、count之類的操作的話，還是MyISAM占優勢些，因為索引所佔空間小，這些操作是需要在內存中完成的 。
聚簇索引 默認是主鍵 ，如果表中沒有定義主鍵，InnoDB 會選擇一個 唯一的非空索引 代替。如果沒有這樣的索引，InnoDB 會 隱式定義一個主鍵 來作為聚簇索引。 InnoDB 只聚集在同一個頁面中的記錄。包含相鄰健值的頁面可能相距甚遠。
❺ SQL中的聚簇索引和非聚簇索引什麼意思
1、聚簇索引是一種對磁碟上實際數據重新組織以按指定的一個或多個列的值排序。由於聚簇索引的索引頁面指針指向數據頁面，所以使用聚簇索引查找數據幾乎總是比使用非聚簇索引快。每張表只能建一個聚簇索引，並且建聚簇索引需要至少相當該表120%的附加空間，以存放該表的副本和索引中間頁。
建立聚簇索引的思想是：
1.1、大多數表都應該有聚簇索引或使用分區來降低對表尾頁的競爭，在一個高事務的環境中，對最後一頁的封鎖嚴重影響系統的吞吐量。
1.2、在聚簇索引下，數據在物理上按順序排在數據頁上，重復值也排在一起，因而在那些包含范圍檢查(between、<、<=、& gt;、>=)或使用group by或order by的查詢時，一旦找到具有范圍中第一個鍵值的行，具有後續索引值的行保證物理上毗連在一起而不必進一步搜索，避免了大范圍掃描，可以大大提高查詢速度。
1.3、在一個頻繁發生插入操作的表上建立聚簇索引時，不要建在具有單調上升值的列(如IDENTITY)上，否則會經常引起封鎖沖突。
1.4、在聚簇索引中不要包含經常修改的列，因為碼值修改後，數據行必須移動到新的位置。
1.5、選擇聚簇索引應基於where子句和連接操作的類型。
聚簇索引的侯選列是：
1、主鍵列,該列在where子句中使用並且插入是隨機的。
2、按范圍存取的列，如pri_order > 100 and pri_order < 200。
3、在group by或order by中使用的列。
4、不經常修改的列。
5、在連接操作中使用的列。
2、SQLServer預設情況下建立的索引是非聚簇索引，由於非聚簇索引不重新組織表中的數據，而是對每一行存儲索引列值並用一個指針指向數據所在的頁面。換句話說非聚簇索引具有在索引結構和數據本身之間的一個額外級。一個表如果沒有聚簇索引時,可有250個非聚簇索引。每個非聚簇索引提供訪問數據的不同排序順序。在建立非聚簇索引時，要權衡索引對查詢速度的加快與降低修改速度之間的利弊。另外，還要考慮這些問題：
2.1、索引需要使用多少空間。
2.2、合適的列是否穩定。
2.3、索引鍵是如何選擇的，掃描效果是否更佳。
2.4、是否有許多重復值。
對更新頻繁的表來說，表上的非聚簇索引比聚簇索引和根本沒有索引需要更多的額外開銷。對移到新頁的每一行而言，指向該數據的每個非聚簇索引的頁級行也必須更新，有時可能還需要索引頁的分理。從一個頁面刪除數據的進程也會有類似的開銷，另外，刪除進程還必須把數據移到頁面上部，以保證數據的連續性。所以，建立非聚簇索引要非常慎重。
非聚簇索引常被用在以下情況:
1、某列常用於集合函數(如Sum,....)。
2、某列常用於join,order by,group by。
3、查尋出的數據不超過表中數據量的20%。
❻ 聚簇索引和非聚簇索引的區別
在《資料庫原理》裡面，對聚簇索引的解釋是:聚簇索引的順序就是數據的物理存儲順序，而對非聚簇索引的解釋是:索引順序與數據物理排列順序無關。正式因為如此，所以一個表最多隻能有一個聚簇索引。
不過這個定義太抽象了。在SQL Server中，索引是通過二叉樹的數據結構來描述的，我們可以這么理解聚簇索引：索引的葉節點就是數據節點。而非聚簇索引的葉節點仍然是索引節點，只不過有一個指針指向對應的數據塊。
上面的解釋很清楚了
❼ sql聚集索引和非聚集索引的區別
聚集索引是邏輯順序與物理順序一致，一張表中職允許有一個聚集索引，主要提供數據的查詢速度；而非聚集索引邏輯順序與物理順序不一致，一張表中可以有多個非聚集索引，對提高數據的插入、刪除、修改有的速度有所提高
❽ SQL Server 聚集索引和非聚集索引的區別分
聚集索引和非聚集索引的根本區別：
1、表記錄的排列順序和與索引的排列順序是否一致。
2、聚集索引一個表只有一個，非聚集索引一個表可以存在多個。
3、聚集索引存儲記錄是物理上連續存在，非聚集索引是邏輯上的連續。
聚集索引優點：
1、以最快的速度縮小查詢范圍。
2、以最快的速度進行欄位排序。
聚集索引使用場合：
1、此列包含有限數目的不同值。
2、查詢的結果返回一個區間的值。
3、查詢的結果返回某值相同的大量結果集。
非聚集索引優點：
1、非聚集索引比聚集索引層次多。
3、添加記錄不會引起數據順序的重組。
非聚集索引使用場合：
1、此列包含了大量數目不同的值。
2、查詢的結束返回的是少量的結果集。
❾ SQL聚集索引和非聚集索引的區別
聚集索引：也稱 Clustered Index。是指關系表記錄的物理順序與索引的邏輯順序相同。由於一張表只能按照一種物理順序存放，一張表最多也只能存在一個聚集索引。與非聚集索引相比，聚集索引有著更快的檢索速度。
MySQL 里只有 INNODB 表支持聚集索引，INNODB 表數據本身就是聚集索引，也就是常說 IOT，索引組織表。非葉子節點按照主鍵順序存放，葉子節點存放主鍵以及對應的行記錄。所以對 INNODB 表進行全表順序掃描會非常快。
非聚集索引：也叫 Secondary Index。指的是非葉子節點按照索引的鍵值順序存放，葉子節點存放索引鍵值以及對應的主鍵鍵值。MySQL 里除了 INNODB 表主鍵外，其他的都是二級索引。MYISAM，memory 等引擎的表索引都是非聚集索引。簡單點說，就是索引與行數據分開存儲。一張表可以有多個二級索引。
關鍵詞：愛可生、開源資料庫、數據監測、資料庫運維