據我瞭解:關於索引的問題在SQL
聚簇索引,通過索引物理定單數據,因此,如果您使用的姓氏作爲一個聚集索引,當你做一個選擇*您將獲得姓氏中按字母順序。
非聚集索引並非物理重新排序數據庫,而是創建一種按您選擇的列排序的查找表。
它在我的書中說,你可以有16列的聚集索引。我以爲你只能選擇1列,因爲它是通過它來重新排序數據庫的?或者如果第一列包含重複項,是否有多個列?
總是使用非聚集索引不是更快嗎,因爲SQL不需要將數據隨機混合?
據我瞭解:關於索引的問題在SQL
聚簇索引,通過索引物理定單數據,因此,如果您使用的姓氏作爲一個聚集索引,當你做一個選擇*您將獲得姓氏中按字母順序。
非聚集索引並非物理重新排序數據庫,而是創建一種按您選擇的列排序的查找表。
它在我的書中說,你可以有16列的聚集索引。我以爲你只能選擇1列,因爲它是通過它來重新排序數據庫的?或者如果第一列包含重複項,是否有多個列?
總是使用非聚集索引不是更快嗎,因爲SQL不需要將數據隨機混合?
聚集索引通過索引物理排序數據,因此如果您使用Surname作爲聚簇索引,當您執行select *時,您將按字母順序得到姓氏。
這不一定是正確的。除非您爲您的查詢提供ORDER BY
,否則不保證訂單。
它在我的書中說,你可以有16列的聚集索引。我以爲你只能選擇1列,因爲它是通過它來重新排序數據庫的?或者如果第一列包含重複項,是否有多個列?
它按照字典順序排列:首先在第一列,然後在第二列(在第一列等的情況下)。
總是使用非聚集索引不是更快嗎,因爲SQL不需要將數據混洗?
聚集索引確實對INSERT
一些開銷,因此有時候最好使需要快速DML
非集羣(如,日誌表等)的表。
但是,聚簇索引允許在聚簇鍵上進行更快的搜索,從而加快該鍵上的連接。
我對聚集索引的理解 - 至少與SQL Server 2005有關 - 是行的排序實際上並不是磁盤上的物理排序。而是維護一個鏈表,對數據進行「邏輯」排序。因此,雖然改變聚集索引可能比非聚集索引有更多的開銷,但它不會像你想像的那樣有問題。
通常情況下,您希望您的聚簇索引位於一個獨特的窄範圍增長列中。您很少想要對隨更新而改變的任何內容進行聚類。
聚集索引不是真正的索引,只是數據存儲在樹中而不是堆。
非聚簇索引通常較窄,因此每頁適合更多行,讀取速度通常更快(顯然需要覆蓋纔能有用)。
這是正確的,磁盤上的物理順序是一個完全獨立的層。 – 2010-06-28 13:24:18