sybase中的聚簇索引與count( )的關係

2021-05-21 20:53:23 字數 1342 閱讀 6724

---- 關鍵字: sybase 聚簇索引 非聚簇索引 查詢計畫 行數  count

在sybase表上建立聚集索引可以提高鍵列的檢索速度。這是索引的主要功能所在。

可是,聚集索引對於統計表上的行數count(*)有沒有改善呢? 答案是否定的。

請看我下面的測試**!

建立一張臨時表test3

向表中插入測試資料

開啟查詢計畫和統計查詢計畫時間的選項

表上沒有加任何索引的情況下。

select count(*) from test4 的查詢計畫為:

select count(1) from test4 的查詢計畫為:

可以看出,count(*) 和count(1) 的執行計畫是相同的。都執行了表掃瞄。

由於表上沒有任何索引可供使用,select count(id) 和 select count(name) 都是執行了表掃瞄。

下面考慮加入主鍵(聚集索引)pk_test4_id

再次執行select count(*) from test4 和 select count(1) from test4

由上可以看出,聚集索引對於select count(*) 幾乎沒有掃瞄影響。堆表和聚集索引表上的count是沒有什麼區別的,甚至於聚集索引表上的io還要多2(這是因為多了兩個聚集索引的資料塊造成的)。其實聚集索引並沒有單獨的保留所有索引列的資訊,而只是將表中的行的物理順序按照聚集索引列的順序整理了一下,因此對聚集索 引的掃瞄和對堆表的掃瞄是一樣的,沒有什麼本質上的區別。

新增id列上的非聚集索引idx_test4_id

此時再次執行select count(*) 和select count(1)。查詢計畫如下:

可以看出查詢引擎使用了非聚集索引idx_test4_id ,執行時間明顯減少。因為計算行數這個操作對於全表掃瞄或是非聚集索引的掃瞄結果是一樣的,而相對來說非聚集索引的資料量是肯定會比表的資料量小很多的,同樣的做一次全部掃瞄所花費的io也就要少很多了。

select count(id) 也是利用了非聚集索引 idx_test4_id。

結論:

count(*)和count(1)執行的效率是完全一樣的。

如果是對特定的列做count的話建立這個列的非聚集索引能對count有很大的幫助。

聚簇索引與非聚簇索引

聚簇索引介紹 聚簇索引並不是一種單獨的索引型別,而是一種資料儲存方式。具體的細節依賴於實現方式,例innodb的聚簇索引實際上在同乙個結構中儲存了b tree索引和資料行。當表有聚簇索引時,他的資料行實際放在索引的葉子頁 leaf page 術語 聚簇 聚簇索引實現 儲存引擎負責實現索引,因此不是所...

聚簇索引與非聚簇索引

mysql的索引主要使用b 樹和雜湊索引的方式進行組織。雜湊索引底層即是雜湊表,查詢時只需要進行一次雜湊操作即可得到位址,查詢速度比較快,但是查詢時操作只適合 的查詢操作,對於範圍查詢不友好,因此只適用於大多數需求為單錶查詢的情況。mysql中常用的兩大引擎myisam和innodb 對於b 樹的使...

聚簇與非聚簇索引

我們平時建立的索引唯一鍵索引,復合索引,字首索引都是非聚簇索引,有的也叫輔助索引 secondary index 其資料結構是b 樹。在mysql中,聚簇索引沒有語句可以生成,在 innodb中,資料是按照主鍵的順序來進行儲存的。葉子節點就是存放每條記錄的。由於表所有資料只能按照乙個b 樹進行排序,...