索引掃描可能不如全表掃描的場景的理解__純粹資料量而言,不涉及CLUSTERING_FACTOR
多塊讀的場景
Full Table Scan --全表掃描
Index Fast Full Scans --索引快速全掃描
單塊讀的場景
Rowid Scans --直接透過Rowid獲取
Index Unique Scans --索引唯一掃描
Index Range Scans --索引區域性掃描
Index Skip Scans --索引跳躍掃描
Index Full Scans --索引全掃描
全表掃描(Full Table Scans FTS)
為實現全表掃描,Oracle 讀取表中所有行,並檢查每一行是否滿足語句的WHERE 限制條件,全表掃描時一次I/O 能讀取多個資料庫塊(db_file_multiblock_read_count引數設定),而不是隻讀取一個資料塊,即多塊讀,這極大的減少了I/O 總次數,提高了系統的吞吐量。
索引掃描(Index Scan或index lookup)
我們先透過index 查詢到資料對應的rowid 值(對於非唯一索引可能返回多個rowid 值),然後根據rowid 直接從表中得到具體的資料,這種查詢方式稱為索引掃描或索引查詢(indexlookup)。
一個rowid 唯一的表示一行資料,該行對應的資料塊是透過一次I/0 得到的,在此情況下該次i/o 只會讀取一個資料庫塊,即單塊讀。
在索引中,除了儲存每個索引的值外,索引還儲存具有此值的行對應的ROWID 值。
索引掃描可以由2 步組成:
1 掃描索引得到對應的rowid 值。
2 透過找到的rowid 從表中讀出具體的資料。
每步都是單獨的一次I/O,但是對於索引,由於經常使用,絕大多數都已經CACHE 到記憶體中,所以第1 步的I/O 經常是邏輯I/O,即資料可以從記憶體中得到。但是對於第2 步來說,如果表比較大,則其資料不可能全在記憶體中,所以其I/O 很有可能是物理I/O,這是一個機械操作,相對邏輯I/O 來說,是極其費時間的。
為什麼多塊讀比單塊讀快,即為什麼有時全表掃描比索引掃描還快
因為邏輯讀物理讀單位是次塊(一次讀取相同或不同塊數情況下,看讀取了多少次,當然邏輯讀沒有IO,只有物理讀有IO),資料總塊數一樣的情況下,多塊讀的話,讀取次數就少,邏輯讀或物理讀就少了,而全表掃描就是多塊讀。
個人理解:一個IO就是一個IO,不管多塊,還是單塊,都是一個次IO。
就好比你花1塊錢買了1顆糖,有人1塊能買10顆糖,消耗的成本其實都是1塊錢。
再比如一秒內要讀完10個塊,單塊讀的話1次讀一個塊,需要10次,多塊讀的話假如1次讀10個塊,需要1次。雖然兩者產生的IO吞吐量都是一樣的,但是前者的IOPS是10,後者的IOPS是1,而一次IO的開啟和結束是要消耗作業系統很多資源的。
案例1
假定多塊讀,一次讀取5個資料庫塊,一張大表10000個資料庫塊,100個索引塊,如果要取出的資料大於總量的20%,使用索引掃描,因為兩步的每一步都是單獨的一次I/O,且每一次I/O都是單塊讀只能讀取一個資料庫塊,所以要掃描的次數=索引塊的數量+全部資料塊的20%的數量=100+10000*20%=2100次,如果都是物理讀那麼其中IO次數就是2100;使用全表掃描,一次就讀取5個資料塊,所以要掃描的次數=全部資料庫/5=10000/5=2000,如果都是物理讀那麼IO次數就是2000。
案例2
假設一張表含有10萬行資料--------100000行
我們要讀取其中20%(2萬)行資料----20000行
這張表一共有10000個資料塊--------10000塊(一個塊10行,每行800位元組)
透過索引讀取20000行資料 = 約20000個table access by rowid = 需要處理20000個塊來執行這個查詢,但是,整個表只有10000個塊,所以:如果按照索引讀取全部的資料的20%相當於將整張表平均讀取了2次。
當然也不能說索引讀取行數大於整表的塊數,那都是全表掃描了,還要考慮讀取的塊是邏輯讀還是物理讀。
如果都是邏輯讀,肯定是索引掃描次數大於全表掃描次數
如果都是物理讀,不CLUSTERING_FACTOR極端的情況下,肯定是索引掃描小於全表掃描
--比如上面案例2索引掃描雖然要處理20000個塊,但是這20000個塊,肯定不是都是物理讀,其中物理讀IO正常情況下大概也就2000個塊(佔整表塊的20%),全表掃描的話如果都是物理讀那麼IO是10000個塊。
當然如果這20%的資料分佈極端雜湊,分佈在了表的所有塊上, 也就是10000個塊上,如果索引掃描和全表掃描都是物理讀,那麼索引掃描的IO=100+10000,全表掃描的IO=10000
所以如果較大表進行索引掃描,取出的資料如果大於總量的5%—10%,使用索引掃描可能效果還不如全表掃描
Full Table Scan --全表掃描
Index Fast Full Scans --索引快速全掃描
單塊讀的場景
Rowid Scans --直接透過Rowid獲取
Index Unique Scans --索引唯一掃描
Index Range Scans --索引區域性掃描
Index Skip Scans --索引跳躍掃描
Index Full Scans --索引全掃描
全表掃描(Full Table Scans FTS)
為實現全表掃描,Oracle 讀取表中所有行,並檢查每一行是否滿足語句的WHERE 限制條件,全表掃描時一次I/O 能讀取多個資料庫塊(db_file_multiblock_read_count引數設定),而不是隻讀取一個資料塊,即多塊讀,這極大的減少了I/O 總次數,提高了系統的吞吐量。
索引掃描(Index Scan或index lookup)
我們先透過index 查詢到資料對應的rowid 值(對於非唯一索引可能返回多個rowid 值),然後根據rowid 直接從表中得到具體的資料,這種查詢方式稱為索引掃描或索引查詢(indexlookup)。
一個rowid 唯一的表示一行資料,該行對應的資料塊是透過一次I/0 得到的,在此情況下該次i/o 只會讀取一個資料庫塊,即單塊讀。
在索引中,除了儲存每個索引的值外,索引還儲存具有此值的行對應的ROWID 值。
索引掃描可以由2 步組成:
1 掃描索引得到對應的rowid 值。
2 透過找到的rowid 從表中讀出具體的資料。
每步都是單獨的一次I/O,但是對於索引,由於經常使用,絕大多數都已經CACHE 到記憶體中,所以第1 步的I/O 經常是邏輯I/O,即資料可以從記憶體中得到。但是對於第2 步來說,如果表比較大,則其資料不可能全在記憶體中,所以其I/O 很有可能是物理I/O,這是一個機械操作,相對邏輯I/O 來說,是極其費時間的。
為什麼多塊讀比單塊讀快,即為什麼有時全表掃描比索引掃描還快
因為邏輯讀物理讀單位是次塊(一次讀取相同或不同塊數情況下,看讀取了多少次,當然邏輯讀沒有IO,只有物理讀有IO),資料總塊數一樣的情況下,多塊讀的話,讀取次數就少,邏輯讀或物理讀就少了,而全表掃描就是多塊讀。
個人理解:一個IO就是一個IO,不管多塊,還是單塊,都是一個次IO。
就好比你花1塊錢買了1顆糖,有人1塊能買10顆糖,消耗的成本其實都是1塊錢。
再比如一秒內要讀完10個塊,單塊讀的話1次讀一個塊,需要10次,多塊讀的話假如1次讀10個塊,需要1次。雖然兩者產生的IO吞吐量都是一樣的,但是前者的IOPS是10,後者的IOPS是1,而一次IO的開啟和結束是要消耗作業系統很多資源的。
案例1
假定多塊讀,一次讀取5個資料庫塊,一張大表10000個資料庫塊,100個索引塊,如果要取出的資料大於總量的20%,使用索引掃描,因為兩步的每一步都是單獨的一次I/O,且每一次I/O都是單塊讀只能讀取一個資料庫塊,所以要掃描的次數=索引塊的數量+全部資料塊的20%的數量=100+10000*20%=2100次,如果都是物理讀那麼其中IO次數就是2100;使用全表掃描,一次就讀取5個資料塊,所以要掃描的次數=全部資料庫/5=10000/5=2000,如果都是物理讀那麼IO次數就是2000。
案例2
假設一張表含有10萬行資料--------100000行
我們要讀取其中20%(2萬)行資料----20000行
這張表一共有10000個資料塊--------10000塊(一個塊10行,每行800位元組)
透過索引讀取20000行資料 = 約20000個table access by rowid = 需要處理20000個塊來執行這個查詢,但是,整個表只有10000個塊,所以:如果按照索引讀取全部的資料的20%相當於將整張表平均讀取了2次。
當然也不能說索引讀取行數大於整表的塊數,那都是全表掃描了,還要考慮讀取的塊是邏輯讀還是物理讀。
如果都是邏輯讀,肯定是索引掃描次數大於全表掃描次數
如果都是物理讀,不CLUSTERING_FACTOR極端的情況下,肯定是索引掃描小於全表掃描
--比如上面案例2索引掃描雖然要處理20000個塊,但是這20000個塊,肯定不是都是物理讀,其中物理讀IO正常情況下大概也就2000個塊(佔整表塊的20%),全表掃描的話如果都是物理讀那麼IO是10000個塊。
當然如果這20%的資料分佈極端雜湊,分佈在了表的所有塊上, 也就是10000個塊上,如果索引掃描和全表掃描都是物理讀,那麼索引掃描的IO=100+10000,全表掃描的IO=10000
所以如果較大表進行索引掃描,取出的資料如果大於總量的5%—10%,使用索引掃描可能效果還不如全表掃描
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/30126024/viewspace-2154715/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 使用索引快速全掃描(Index FFS)避免全表掃描的若干場景索引Index
- oracle 全表掃描,索引範圍掃描與塊的理解Oracle索引
- Oracle中存取資料掃描Table及索引的方式(全表掃描,索引掃描等)Oracle索引
- MySQL中的全表掃描和索引樹掃描MySql索引
- 索引全掃描和索引快速全掃描的區別索引
- 【MySQL】全索引掃描的bugMySql索引
- (轉)索引掃描還是全表掃描(Index Scan Or Full Table Scan)索引Index
- 轉)索引掃描還是全表掃描(Index Scan Or Full Table Scan)索引Index
- 優化全表掃描優化
- delete 與全表掃描delete
- 有索引卻走全表掃描的實驗分析索引
- 查詢全表掃描的sqlSQL
- delete 刪除資料 全表掃描還是掃描所有塊的測試delete
- 全表掃描的cost 與 索引掃描Cost的比較 – 無直方圖(10.1.0.3以後)索引直方圖
- 【Oracle】 索引的掃描方式Oracle索引
- ORACLE全表掃描查詢Oracle
- 查詢全表掃描語句
- oracle優化:避免全表掃描Oracle優化
- 抓取全表掃描的表,篩選和分析
- oracle是如何進行全表掃描的Oracle
- 優化Oracle with全表掃描的問題優化Oracle
- oracle實驗記錄(分割槽全表掃描(全區掃描) FTS 時候的成本計算)Oracle
- mysql下建立索引讓其index全掃描MySql索引Index
- 解讀Oracle 索引掃描Oracle索引
- 走索引掃描的慢查詢索引
- 24_Oracle資料庫全表掃描詳解(四)_全表掃描生產最佳化案例三則Oracle資料庫
- 掃描技術和掃描工具
- 一條全表掃描sql語句的分析SQL
- 優化Oracle with全表掃描的問題(二)優化Oracle
- SQL Server之旅(2):理解萬惡的表掃描SQLServer
- noworkload下全表掃描cost的計算
- 執行計劃-資料訪問方式(全表掃描與4種索引的方式)索引
- AWVS掃描器掃描web漏洞操作Web
- 理解資料庫掃描方法-利用掃描方法對資料儲存進行優化資料庫優化
- 使用全表掃描快取大表的相關問題快取
- win10系統掃描器提示掃描不到掃描器如何解決Win10
- 23_Oracle資料庫全表掃描詳解(三)Oracle資料庫
- 22_Oracle資料庫全表掃描詳解(二)Oracle資料庫