上面兩位朋友的問題有乙個共同特點,就是希望有示例,因為這樣容易讓他們更加容易理解。但從我的角度來講,有示例只能給你提供乙個參考而已,夠不成是否容易消化的關鍵因素,最好的辦法是,通過自己的理解,自己有能力去做相應的實驗,這樣效果才是最好的,你也會發現更多的問題,每個專案都有自己的特點,所以效能優化這塊也是需要因地制宜的。
它的結構完全符合聚集索引的儲存結構,所以我們說聚集索引的儲存結構為b+樹。
聚集索引的選擇是資料庫設計的基石,不好的聚集索引設計不光是增加查詢的執行時間,而且是乙個瀑布性的影響:
如何選擇表的聚集索引
建立如下表,為了測試只包含兩個字段,乙個在型別為int的id上建立聚集索引,乙個在型別為uniqueindentifier的code上建立聚集索引,且為唯一聚集索引。
create table dbo.narrowstudent
(id int identity(1, 1) , -- unique
code uniqueidentifier -- unique
) ;create unique clustered index pk_narrowstudent_id
on narrowstudent(id)
create table dbo.student
(id int identity(1, 1) , -- unique
code uniqueidentifier -- unique
) ;create unique clustered index pk_student_code
on student(code)
再分別插入一條資料:
insert into dbo.narrowstudent
( code )
values ( newid() -- code - uniqueidentifier
)insert into dbo.student
( code )
values ( newid() -- code - uniqueidentifier
)
看下行大小:
注意為什麼寬度為27而不是20呢(id型別為int,占用4位元組,code為guid占用16位元組),這是sql sever內部為了維護可空值或者是可變長值而預留7位空間。
我們再多插入些資料來做對比,插入的指令碼就貼了,然後我們看下兩表所占用的空間對比:採用了int做為主鍵的表資料占用為320k,選用guid為主鍵的表占用為464k,明顯較int要費磁碟空間。
索引健康情況
下圖中紅線部分有乙個非常重要的引數:掃瞄密度,明顯可以看出在連續對錶進行資料插入後,int自增性為主鍵的索引密度比guid為主鍵的索引密度要大的多。這說明前者產生的索引碎片更低。
聚集索引對非聚集索引的影響
兩者最大的區別在於聚集索引的葉級儲存了資料本身,但非聚集索引葉結點不存在資料記錄,只是乙個指向聚集索引的指標,這就意味著在非聚集索引的所有級別中都包含了聚集索引的指標,聚集索引的大小會直接影響非聚集索引的大小。
為上面兩個表,增加乙個addressinfo的字段,且建立非聚集索引,這裡為了測試的有效性,不要使用如下語句新增列之後做測試,因為後期表結構的變更會引起比較明顯的資料分頁情況,建議建立新表來測試,下面對比在兩個表中,字段型別以及值者相同以及表資料條數一樣的情況下非聚集索引的大小情況,結論是在其它條件都相同的情況下,誰的主鍵大誰占用的索引空間就更大。
主鍵為int的非聚集索引
主鍵為guid的非聚集索引
上面提到過聚集索引可以選擇具有重複值的列,但在內部會維護乙個型別為uniqueifier的字段,長度為4位元組,同時還會需要維護可變長列,同樣會占用4位元組,所以sql server會使每行的大小增加8位元組,資料類似如下**:
idfirst name
uniqueifier
1tom
null
2tom13
andy
null
關鍵字第一次出現時,uniqueifier賦值為null,當第二次出現時,就開始計數累加。賦值為null時占用0位元組,可從如一圖得到結果:
再插入一條重複資料之後再檢視行大小,由11位元組變成19位元組了,這多出來的8位元組,就是當uniqueifier值不等於空之後的結果。
這裡列乙個場景:如果選擇乙個時間欄位做為主鍵的話,此時瞬間批量插入多條資料,那麼時間在某一批資料中都是相同的,這時就需要頻繁維護uniqueifier。重複的資料越多,後續索引的命中就會越困難,同時由於行大小變大會降低磁碟空間的應用,從而降低io效能。
這篇內容比較長,先講其中的窄列以及唯一性這兩原則吧,這只是從效能角度來區分,沒有涉及具體業務,所以並不是說一定要按此標準來選擇聚集索引,後面再分析其它的幾條規則。
聚集索引與非聚集索引 SQL
介紹 查詢資料表中的行的兩種方式,不管聚集索引,還是非聚集索引,都是用b 樹來實現的,關於b樹的介紹 clustered index 聚集索引 類似於使用字典的拼音索引來找字 表必須按順序排列,聚集索引的葉節點就是實際的資料頁,每一頁為乙個頁節點,訪問資料時表得保持順序故會減低速度,每個表只能有乙個...
SQL 中聚集索引
今天做個試驗,驗證下聚集索引是不是改變表的物理結構。第一步 建立表 只有聚集索引 create table department departmentid int identity 1,1 not null primary key,name nvarchar 200 not null,groupna...
SQL的聚集索引
其實對於非專業的資料庫操作人員來講,例如軟體開發人員,在很大程度上都搞不清楚資料庫索引的一些基本知識,有些是知其一不知其二,或者是知其然不知其所以然。造成這種情況的主要原因我覺的是行業原因,有很多公司都有自己的dba團隊,他們會幫助你優化sql,開發人員即使不懂優化問題也不大,所以開發人員對這方面也...