索引掃描可能不如全表掃描的場景的理解__純粹資料量而言,不涉及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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 全表掃描和全索引掃描索引
- MySQL中的全表掃描和索引樹掃描MySql索引
- 全表掃描和全索引掃描繼續(PG-TiDB)索引TiDB
- [20210220]全索引掃描快速索引掃描的邏輯讀.txt索引
- [20190815]索引快速全掃描的成本.txt索引
- 【Oracle】 索引的掃描方式Oracle索引
- oracle是如何進行全表掃描的Oracle
- 掃描器的存在、奧普 掃描器
- 24_Oracle資料庫全表掃描詳解(四)_全表掃描生產最佳化案例三則Oracle資料庫
- AWVS掃描器掃描web漏洞操作Web
- 技術分享 | 為什麼 SELECT 查詢選擇全表掃描,而不走索引?索引
- 理解資料庫掃描方法-利用掃描方法對資料儲存進行優化資料庫優化
- win10系統掃描器提示掃描不到掃描器如何解決Win10
- AppBoxFuture: 二級索引及索引掃描查詢資料APP索引
- 掃描器
- 掃描王 for Mac專業圖片掃描工具Mac
- 關係型資料庫全表掃描分片詳解資料庫
- 23_Oracle資料庫全表掃描詳解(三)Oracle資料庫
- 22_Oracle資料庫全表掃描詳解(二)Oracle資料庫
- 21_Oracle資料庫全表掃描詳解(一)Oracle資料庫
- [20210219]全表掃描邏輯讀問題.txt
- PostgreSQL技術內幕(七)索引掃描SQL索引
- 什麼是漏洞掃描?漏洞掃描功能有哪些?
- PostgreSQL DBA(55) - MVCC#8(對全表掃描的影響)SQLMVCC#
- python掃描埠Python
- 目錄掃描
- 埠掃描器
- DAST 黑盒漏洞掃描器 第四篇:掃描效能AST
- 電腦掃描檔案怎麼掃描 win10電腦掃描檔案方法介紹Win10
- RustScan: 能在3秒內掃描65k個埠的Rust掃描工具Rust
- TWAIN掃描識別控制元件:Web應用程式的掃描器SDKAI控制元件Web
- 怎麼解決因全表掃描帶來的 Buffer Pool 汙染
- 獨立按鍵的掃描
- redis的bigkey掃描指令碼Redis指令碼
- 京東掃描平臺EOS—JS掃描落地與實踐JS
- Zenmap(埠掃描工具)
- P2032 掃描
- direasch目錄掃描