Weitere ähnliche Inhalte Ähnlich wie 資料庫索引數據結構及主鍵設計(b+tree)(part 1) (20) Mehr von Yi-Feng Tzeng (20) 資料庫索引數據結構及主鍵設計(b+tree)(part 1)2. 2016
2/129
自我介紹
♪ Muzik Online (www.muzikair.com) 總工程師。
♪ Paganini+ (http://www.paganiniplus.com/) 技術長。
♪ BELP (fb.com/belp.general) 共同創辦人。
♪ CHROOT (www.chroot.org) 成員。
♪ 講師經驗
PHPConf, Modern Web Taiwan, MOPCON, WebConf, COSCUP, JSDC Taiwan,
DrupalCamp Taiwan, OSDC, HITCON, ...
♪ 略懂智慧財產權、資訊安全及軟體程式設計。
♪ 『略懂諸葛』。
♪ 沉浸於『人性』、『法律』與『科技』的三角關係中。
3. 2016
3/129
問題 1: UUID ?
Q: 資料庫 Primary key 使用 UUID 比較快?
Serial/Auto-Increment
1
2
3
4
5
...
UUID
3a5e439b-eeb4-4074-8b23-51c2cdd35421
1bb19e6b-9c0c-475e-a7b3-f01a6b4cd496
af4c8b80-4bf5-4bf3-a4e3-a71bed920f10
e62acb5b-a393-4707-9aa5-90f79352eb4b
2e199d72-4e49-4ace-a504-419da63878f5
...
5. 2016
5/129
問題 1 ( 修正 ): MySQL UUID ?
Q: MySQL 的 Primary key 使用 UUID 比較快?
Serial/Auto-Increment
1
2
3
4
5
...
UUID
3a5e439b-eeb4-4074-8b23-51c2cdd35421
1bb19e6b-9c0c-475e-a7b3-f01a6b4cd496
af4c8b80-4bf5-4bf3-a4e3-a71bed920f10
e62acb5b-a393-4707-9aa5-90f79352eb4b
2e199d72-4e49-4ace-a504-419da63878f5
...
7. 7/129
2016
問題 1 ( 修正 ): MySQL UUID ?
UUID 目前公定有五種版本:
➀ Version 1 (MAC address & date-time)
➁ Version 2 (DCE Security)
➂ Version 3 (MD5 hash & namespace)
➃ Version 4 (Random)
➄ Version 5 (SHA-1 hash & namespace)
Ref: https://en.wikipedia.org/wiki/Universally_unique_identifier
8. 8/129
2016
問題 1 ( 修正 ): MySQL UUID ?
UUID 目前公定有五種版本:
➀ Version 1 (MAC address & date-time)
➁ Version 2 (DCE Security)
➂ Version 3 (MD5 hash & namespace)
➃ Version 4 (Random)
➄ Version 5 (SHA-1 hash & namespace)
Ref: https://en.wikipedia.org/wiki/Universally_unique_identifier
Version 2 未在 UUID 規格中定義,少見
9. 9/129
2016
問題 1 ( 修正 ): MySQL UUID ?
UUID 目前公定有五種版本:
➀ Version 1 (MAC address & date-time)
➁ Version 2 (DCE Security)
➂ Version 3 (MD5 hash & namespace)
➃ Version 4 (Random)
➄ Version 5 (SHA-1 hash & namespace)
Ref: https://en.wikipedia.org/wiki/Universally_unique_identifier
10. 10/129
2016
問題 1 ( 修正 ): MySQL UUID ?
UUID 類循序式 ( 通常後序產生的值 > 先前產生的值 ) :
➀ Version 1 (MAC address & date-time)
UUID 亂序式 ( 值的大小沒有前後關係 ) :
➂ Version 3 (MD5 hash & namespace)
➃ Version 4 (Random)
➄ Version 5 (SHA-1 hash & namespace)
11. 11/129
2016
問題 1 ( 修正 ): MySQL UUID ?
UUIDv1 的範例:
2190718a-c7a3-61e2-aa34-024281ed9db5
2191f33e-c7a3-61e2-9b92-024281ed9db5
2192cc0a-c7a3-61e2-be4c-024281ed9db5
21939950-c7a3-61e2-9aad-024281ed9db5
21945ff2-c7a3-61e2-90fc-024281ed9db5
219525f4-c7a3-61e2-99df-024281ed9db5
Time
12. 12/129
2016
問題 1 ( 修正 ): MySQL UUID ?
UUIDv4 的範例:
3a5e439b-eeb4-4074-8b23-51c2cdd35421
1bb19e6b-9c0c-475e-a7b3-f01a6b4cd496
af4c8b80-4bf5-4bf3-a4e3-a71bed920f10
e62acb5b-a393-4707-9aa5-90f79352eb4b
2e199d72-4e49-4ace-a504-419da63878f5
8cf2e49f-8ae9-43f2-a84d-78cb323114a3
Time
14. 14/129
2016
問題 1 ( 修正 ): MySQL UUID ?
Ref: https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/
16. 16/129
2016
問題 1 ( 修正 ): MySQL UUID ?
GUID 是 Microsoft 用詞,指的其實類似於 UUID ,
但實作方式不一樣。
Microsoft 對於 GUID 的實作至少有兩種:
➀ 基於 UuidCreate 的 NEWID(SQL) ;
➁ 基於 UuidCreateSequential 的 NEWSEQUENTIALID(SQL) 。
其中 NEWID 是亂序式,而 NEWSEQUENTIALID 是循序式。
20. 20/129
2016
索引數據結構 : B-tree 索引
目的:尋找【欄位一為 5 的資料】
操作: 4 , O(logbn)
缺點:全表掃描需要遍歷樹
資料表:
1 user1 pass1
2 user2 pass2
3 user3 pass3
4 user4 pass4
5 user5 pass5
8
3 6
1 2 4 5 7
21. 21/129
2016
索引數據結構 : B+tree 索引
目的:尋找【欄位一為 5 的資料】
優點:全表掃描不需遍歷樹
資料表:
1 user1 pass1
2 user2 pass2
3 user3 pass3
4 user4 pass4
5 user5 pass5
13
4 7
1 2 3 4 5 6 7
22. 22/129
2016
索引數據結構 : B+tree 索引
目的:尋找【欄位一為 5 的資料】
操作: 4 , O(logbn)
優點:全表掃描不需遍歷樹
資料表:
1 user1 pass1
2 user2 pass2
3 user3 pass3
4 user4 pass4
5 user5 pass5
13
4 7
1 2 3 4 5 6 7
13
b
23. 2016
23/129
問題 2: B+tree
Q: 哪些資料庫索引數據結構支援 B+tree ?
MySQL
Oracle
Microsoft SQL Server
PostgreSQL
MongoDB
CouchDB
LevelDB
RocksDB
HBase
Cassandra
Riak
NessDB
BoltDB
TokuDB
Aerospike
Couchbase
24. 24/129
2016
問題 2: B+tree
Q: 哪些資料庫索引數據結構支援 B+tree ?
MySQL
Oracle
Microsoft SQL Server
PostgreSQL
MongoDB
CouchDB
LevelDB
RocksDB
HBase
Cassandra
Riak
NessDB
BoltDB
TokuDB
Aerospike
Couchbase
27. 27/129
2016
索引頁分裂 : 循序式新增資料
操作:新增 25( 假設頁只能存三筆資料 )
9 18
21 24
19 20 21 22 23 24
25
p1
p10
p12p11
9 18
21 24 25
19 20 21 22 23 24
p1
p10
p12p11
25
p13
latch
latch
hotspot
30. 30/129
2016
索引頁分裂 : I/O 與 Page Size
資料庫 I/O 以 Page 為單位。
儲存引擎的 Page Size :
➊ PostgreSQL 8KB
➋ MySQL/InnoDB 16KB(default)
➌ MongoDB/MMAPv1 dynamic (powered by 2)
➍ MongoDB/WiredTiger 32KB(default)
➎ Percona/TokuDB 64KB(default)
31. 31/129
2016
索引頁分裂 : 循序式新增 I/O
9 18
21 24 25
19 20 21 22 23 24
25
p1
p10
p12p11
25
p13
latch
latch
Block N+1 Block N+2 Block N+3 p11 p12 p13p10
I/O
hotspot?
hotspot
32. 32/129
2016
索引頁分裂 : 循序式新增 I/O
如果 Page Size 比較大?
Block N+1 Block N+2 Block N+3 p11 p12 p13p10
I/O
Block N+1 Block N+2 p13p12p11p10
I/OI/O
33. 33/129
2016
索引頁分裂 : 亂序式新增 I/O
Block N+3 Block N+4
I/O
p2 p3 p4p1 # # #p5
20
6 12
2 4 6 8 10 12
20
4 6 12
2 4 5 6 8 10 12
p1 p1
p2 p2
p4p3 p3 p4p5
latch
I/O
5
34. 34/129
2016
索引頁分裂 : 亂序式新增 I/O
如果 Page Size 比較大?
Block N+4p4p3p2p1
I/OI/O
Block N+3 Block N+4
I/O
p2 p3 p4p1 # # #p5
I/O
#p5
I/O
36. 36/129
2016
索引子頁結構 : Non-clustered index
以 B+tree 為例
特色:子頁不包括資料本身 ( 指針指向資料 )
補充:對應的資料表稱 Heap table
資料表:循序式
1 user1 pass1
2 user2 pass2
3 user3 pass3
4 user4 pass4
5 user5 pass5
13
4 7
1 2 3 4 5 6 7
38. 38/129
2016
索引子頁結構 : Clustered index
以 B+tree 為例
特色:子頁包括資料本身 ( 不需指針指向資料 )
補充:對應的資料表稱 Index Organized Table(IOT)
資料表:循序式與亂序式都一樣
13
4 7
1 2 3 4 5 6 7
1 user1 pass1
2 user2 pass2
3 user3 pass3
4 user4 pass4
5 user5 pass5
40. 40/129
2016
索引子頁結構 : Clustered index
Clustered index(IOT)
循序式
➀ 資料佔頁空間,頁存放的資料量少,頁分裂頻繁。
➁ 搜尋至頁索引時,因包括資料本身,無額外指針開銷。
➂ Hotspot 發生在樹最右下的頁,但循序寫及合併寫機率高。
亂序式
➀ 資料佔頁空間,頁存放的資料量少,頁分裂頻繁。
➁ 搜尋至頁索引時,因包括資料本身,無額外指針開銷。
➂ 為了維持循序,發生大量的頁分裂。
41. 41/129
2016
索引子頁結構 : Clustered index
Q: 循序式 / 亂序式 vs. I/O Scheduler vs. Filesystem vs. HDD / Flash / Fusion IO ?
循序式
亂序式
CFQ
Deadline
NOOP
HDD
Flash
Fusion IO
Ext4
XFS
ZFS
BtrFS
44. 44/129
2016
Range scan: Heap table w/ 循序式
SELECT * FROM x WHERE y BETWEEN 1 AND 7;
1 user1 pass1
2 user2 pass2
3 user3 pass3
4 user4 pass4
5 user5 pass5
6 user6 pass6
7 user7 pass7
13
4 7
1 2 3 4 5 6 7
Block N+3 ...
p1
p3
I/O
p2
p1 p2 p3 p4
I/O
Block N+M
45. 45/129
2016
Range scan: Heap table w/ 亂序式
SELECT * FROM x WHERE y BETWEEN 1 AND 7;
1 user1 pass1
4 user4 pass4
5 user5 pass5
2 user2 pass2
3 user3 pass3
7 user7 pass7
6 user6 pass6
13
4 7
1 2 3 4 5 6 7
I/O
p5 p7 p3 p6
I/O I/OI/O
p1 # p2 p4...
p4
p7
p5
p1
p3
p2
p6
46. 46/129
2016
Range scan: Heap table w/ 亂序式
I/O
p5 p7 p3 p6
I/O I/OI/O
p1 # p2 p4...
Ref: http://etutorials.org/SQL/Postgresql/Part+I+General+PostgreSQL+Use/Chapter+4.+Performance/Gathering+Performance+Information/
47. 47/129
2016
Range scan: IOT w/ 循序式 & 亂序式
SELECT * FROM x WHERE y BETWEEN 1 AND 7;
13
4 7
1 2 3 4 5 6 7
1 user1 pass1
2 user2 pass2
3 user3 pass3
4 user4 pass4
5 user5 pass5
6 user6 pass6
7 user7 pass7
p1
p3
p2
Block N+3 ...
I/O
p1 p2 p3 p4
I/O
Block N+M
49. 49/129
2016
問題 3
Heap table IOT
MySQL/MyISAM O X
MySQL/InnoDB X O
Oracle O O
Microsoft SQL Server O O
PostgreSQL O X
MongoDB/MMAPv1 O X
MongoDB/WiredTiger O X
CouchDB X O
52. 52/129
2016
特別篇 1: MySQL 生態系
MySQL
➀ 官方,有 Oracle 技術支持及專利保護。
➁ 最新的 MySQL 5.7 擁有大量新特性。
➂ 商業因素預設不會接受其他分支的特性。
Percona
➀ drop-in compatible with (official) MySQL 。
➁ 針對 MySQL 額外新增許多特性。
➂ 額外支援 XtraDB / TokuDB 等引擎。
➃ 商業特性可接受其他所有分支的特性。
53. 53/129
2016
特別篇 1: MySQL 生態系
MariaDB
➀ drop-in replacement for (official) MySQL 。
➁ MariaDB 10 基於 MySQL 5.6 ,但不相容 5.7 。
➂ 額外支援 XtraDB / TokuDB / Cassandra / CONNECT 等引擎。
➃ 至今仍沒有穩定的自我開發儲存引擎。
XtraDB / TokuDB 都屬 Percona 公司。
WebScaleSQL
➀ 基於 5.6 ,但可收納 5.7 特性。
➁ 專針對特大型 Web 公司需求而生,小心駕馭。
57. 57/129
2016
特別篇 2: PostgreSQL (Fusion IO)
Fusion IO 只特別支援 Oracle / MySQL / Percona / MariaDB ?
Ref: https://www.sandisk.com/business/datacenter/resources/overviews/accelerate-mysql-open-source-databases
58. 58/129
2016
特別篇 2: PostgreSQL (Fusion IO)
Fusion IO 可讓 MySQL 免除 double write 。
Ref: https://www.sandisk.com/business/datacenter/resources/overviews/accelerate-mysql-open-source-databases
59. 59/129
2016
特別篇 2: PostgreSQL (Fragmentation)
PostgreSQL(HOT) 天性無法避免 fragmentation 。
Ref: http://etutorials.org/SQL/Postgresql/Part+I+General+PostgreSQL+Use/Chapter+4.+Performance/Gathering+Performance+Information/
60. 60/129
2016
特別篇 2: PostgreSQL (Index Bloat)
PostgreSQL(non HOT updates) 天性無法避免 index bloat 。
Ref: PostgreSQL 9.0 High Performance [PACKT] (2010) (p171)
63. 63/129
2016
特別篇 2: PostgreSQL (Merge IO)
PostgreSQL 沒有類似 MySQL 的 Change Buffer 。
Ref: http://www.slideshare.net/morgo/inno-db-presentation (p9)
64. 64/129
2016
特別篇 2: PostgreSQL (Merge IO)
MySQL Insert Buffering( 現在改名 Change Buffer) :
1. Reducing the number of disk i/o operations by merging i/o
requests to the same block.
2. Some random i/o operations can be sequential.
Ref: http://www.percona.com/files/presentations/percona-live/london-2011/PLUK2011-linux-and-hw-optimizations-for-mysql.pdf (p17)
66. 66/129
2016
特別篇 2: PostgreSQL ( 儲存引擎 )
Microsoft SQL Server / Oracle 支援 Heap table 及 IOT ,
可依各資料表的特性分別採用。
MySQL 及 MongoDB 支援可抽換儲存引擎,也可依資料表的
特性分別採用。
但 PostgreSQL 只有一個儲存引擎,也只支援 Heap table 。
72. 72/129
2016
特別篇 3: MongoDB
Index
➀ ”統一命名為 _id”
➁ ”新增若未指定 _id” 值,會使用 ObjectId
➂ ObjectId 為 12-byte BSON 型態
➊ 4-byte 為 UNIX 紀元時間
➋ 3-byte 為機器識別碼
➌ 2-byte 為 Process ID
➍ 3-byte 為隨機值
Ref: https://docs.mongodb.org/manual/reference/object-id/
“_id” : ObjectId(“563479cc8a8a4246bd27d784”)
“_id” : ObjectId(“563479d48a8a4246bd27d785”)
“_id” : ObjectId(“563479df8a8a4246bd27d786”)
循序式 UUID
76. 76/129
2016
特別篇 3: MongoDB
MMAPv1 儲存引擎
➀ Memory-mapped files
➁ Padding
➂ Fragmentation
➃ Collection-level locking (WiredTiger 為 Document-level)
Ref: http://sql-vs-nosql.blogspot.tw/2013/11/indexes-comparison-mongodb-vs-mssqlserver.html
77. 77/129
2016
特別篇 3: MongoDB
MMAPv1 儲存引擎
➀ Memory-mapped files
➁ Padding
➂ Fragmentation
➃ Collection-level locking (WiredTiger 為 Document-level)
➄ MongoDB 3.2 以前為預設引擎, 3.2 後換 WiredTiger
Ref: https://docs.mongodb.org/manual/core/wiredtiger/
78. 78/129
2016
特別篇 3: MongoDB
MMAPv1 的 Fragmentation 問題
Ref: http://www.slideshare.net/mongodb/7-managing-a-maturing-mongo-db-ecosystem-charity-majors (p35)
左邊是大量 Fragmentation ;
右邊是修復 Fragmentation 後
80. 80/129
2016
特別篇 3: MongoDB
MMAPv1 的 Fragmentation 問題
動作:更新 Document 3
情況一:新的 Document 3 大小 <= 原先大小
Collection :
{Document 1}
{Document 2}
{Document 3}
{Document 4}
{Document 5}
{Document 1}
{Document 2}
{Document 3‘}
{Document 4}
{Document 5}
81. 81/129
2016
特別篇 3: MongoDB
MMAPv1 的 Fragmentation 問題
動作:更新 Document 3
情況二:新的 Document 3 大小 > 原先大小
Collection :
{Document 1}
{Document 2}
{Document 3}
{Document 4}
{Document 5}
{Document 1}
{Document 2}
Free
{Document 4}
{Document 5}
{Document 3‘}
83. 83/129
2016
特別篇 3: MongoDB
MMAPv1 的 Fragmentation 問題
動作:新增 Document 6
情況一: Document 6 大小 <= 原先 Document 3 (Free) 大小
Collection :
{Document 1}
{Document 2}
{Document 6}
{Document 4}
{Document 5}
{Document 3‘}
{Document 1}
{Document 2}
Free
{Document 4}
{Document 5}
{Document 3‘}
84. 84/129
2016
特別篇 3: MongoDB
MMAPv1 的 Fragmentation 問題
動作:新增 Document 6
情況二: Document 6 大小 > 原先 Document 3 (Free) 大小
Collection :
{Document 1}
{Document 2}
Free
{Document 4}
{Document 5}
{Document 3‘}
{Document 6}
{Document 1}
{Document 2}
Free
{Document 4}
{Document 5}
{Document 3‘}
85. 85/129
2016
特別篇 3: MongoDB
特色與改善
➀ Sharding/Replica 較容易
( 但 Sharding/Replica 只有 Primary 可寫 )
➁ Dynamic schema ( 不是 Schemaless)
➂ 儲存引擎可抽換
➊ MMAPv1
➋ WiredTiger
➌ inMemory
➍ Devnull
➎ (RocksDB)
86. 86/129
2016
特別篇 3: MongoDB
特色與改善
➃ 寫入的 Locking level 改善
2.2 版前, Process-level lock ,一個 Mongod 實例一個鎖
2.8 版前, Database-level lock ,一個 DB 一個鎖
2.8 版之後, WiredTiger 提供 Document-level lock
3.0 版之後, MMAPv1 改為 Collection-level lock
Ref: http://sql-vs-nosql.blogspot.tw/2013/11/indexes-comparison-mongodb-vs-mssqlserver.html
87. 87/129
2016
特別篇 3: MongoDB
特色與改善
➄ 支援 MapReduce
2.4 版前,使用 SpiderMonkey ,是 single threaded
2.4 版之後,改用 V8 engine ,改善問題
➅ Single thread model ,大多時候只用到一顆 CPU
(WiredTiger 已支援 Multiple CPUs)
90. 90/129
2016
特別篇 4: RDMBS or NoSQL ?
不過 RDBMS 及 NoSQL 的分界會愈來愈小。
過去的一些 RDBMS 已開始支援 NoSQL 特性,
Microsoft SQL Server / Oracle / MySQL /
PostgreSQL 都確定支援 JSON(B) 操作。
Percona / MariaDB 可抽換為 TokuDB 引擎,
MariaDB 更可抽換為 Cassandra 引擎。
NoSQL 等也開始支援強一致性。
91. 91/129
2016
特別篇 4: RDMBS or NoSQL ?
不過 RDBMS 及 NoSQL 的分界會愈來愈小。
過去的一些 RDBMS 已開始支援 NoSQL 特性,
Microsoft SQL Server / Oracle / MySQL /
PostgreSQL 都確定支援 JSON(B) 操作。
Percona / MariaDB 可抽換為 TokuDB 引擎,
MariaDB 更可抽換為 Cassandra 引擎。
NoSQL 等也開始支援強一致性。
NewSQL
92. 2016
92/129
特別篇 5: 黑暗執行緒案例
Q: 試著分析黑暗執行緒的文章。
【 GUID Primary Key 資料庫避雷守則】
Ref: http://blog.darkthread.net/post-2016-01-29-guid-as-pk-on-db.aspx
93. 93/129
2016
特別篇 5: 黑暗執行緒案例
以架構設計而言,我更傾向讓應用伺服器決定 GUID / UUID 的值,
理由有幾個。
➊ 未來若需要異質資料庫彼此交換資料, GUID / UUID 的衝突會
更小。例如若 SQL Server 要與 MySQL 交換, MySQL 沒有 NEWID /
NEWSEQUENTIALID 函式,所以勢必要用另一種算法來計算 UUID ,
而算法不同就可能破壞原本 GUID / UUID 不會重複的機率。
➋ 資料庫在整體架構中,是最難以擴展的,所以我傾向讓資料庫做愈少
事情愈好。 GUID / UUID 是需要計算的,即使開銷很低,但若量大還是
很可觀,所以我還是會把計算的成本移至應用伺服器處理。
94. 94/129
2016
特別篇 5: 黑暗執行緒案例
➌ 應用伺服器脫離 SQL Server 後,就無法使用 NEWID 及
NEWSEQUENTIALID ,所以需要找 UUID 產生器。 UUID 產生器有
幾種版本, UUIDv1 是類循序性, UUIDv4 是亂序性,可以依業務
場景選擇所需。而且 UUIDv1 的類循序性不像 NEWSEQUENTIALID
這麼容易猜測。
➍ 大規模架構中,全循序性 Insert 不一定是好事。想像一下,順序性
Insert 時,所有資料會集中在樹最右下角的 Leaf Page Insert ,當
Page 滿後,就必須 Page Split ,此時就一定有 Latch 。 Latch 會減
緩 Insert 的速度。再加上實際在硬碟寫入的 Block 也會變成是 Hotspot 。
所以有時候,適當非循序性所造成的 Fragmentation 有時反而會更快。
最後有可能會變成全順序性 Insert 不一定最快,全隨機性 Insert 也不
一定最好,反而中間找平衡才是最佳的。而這時把 UUID 的計算移到應
用伺服器,剛好可以滿足這點。
98. 98/129
2016
特別篇 5: 黑暗執行緒案例
假設已有五筆資料
5b.. cb..
07.. 3b.. 5b.. 9e.. cb..
3 5
1 2 3 4 5
[SeqNo] [FlowId] ...
1 07.. ...
2 9e.. ...
3 3b.. ...
4 cb.. ...
5 5b.. ...
1 3 5 2 4
Nonclustered Index ( 亂序式 )
Clustered Index ( 循序式 )
99. 99/129
2016
特別篇 5: 黑暗執行緒案例
尋找【 WHERE FlowId = “5b..” 】
IO 次數: 0
5b.. cb..
07.. 3b.. 5b.. 9e.. cb..
3 5
1 2 3 4 5
[SeqNo] [FlowId] ...
1 07.. ...
2 9e.. ...
3 3b.. ...
4 cb.. ...
5 5b.. ...
1 3 5 2 4
Nonclustered Index ( 亂序式 )
Clustered Index ( 循序式 )
100. 100/129
2016
特別篇 5: 黑暗執行緒案例
尋找【 WHERE FlowId = “5b..” 】
IO 次數: 1
5b.. cb..
07.. 3b.. 5b.. 9e.. cb..
3 5
1 2 3 4 5
[SeqNo] [FlowId] ...
1 07.. ...
2 9e.. ...
3 3b.. ...
4 cb.. ...
5 5b.. ...
1 3 5 2 4
Nonclustered Index ( 亂序式 )
Clustered Index ( 循序式 )
101. 101/129
2016
特別篇 5: 黑暗執行緒案例
尋找【 WHERE FlowId = “5b..” 】
IO 次數: 2
5b.. cb..
07.. 3b.. 5b.. 9e.. cb..
3 5
1 2 3 4 5
[SeqNo] [FlowId] ...
1 07.. ...
2 9e.. ...
3 3b.. ...
4 cb.. ...
5 5b.. ...
1 3 5 2 4
Nonclustered Index ( 亂序式 )
Clustered Index ( 循序式 )
102. 102/129
2016
特別篇 5: 黑暗執行緒案例
尋找【 WHERE FlowId = “5b..” 】
IO 次數: 3
5b.. cb..
07.. 3b.. 5b.. 9e.. cb..
3 5
1 2 3 4 5
[SeqNo] [FlowId] ...
1 07.. ...
2 9e.. ...
3 3b.. ...
4 cb.. ...
5 5b.. ...
1 3 5 2 4
Nonclustered Index ( 亂序式 )
Clustered Index ( 循序式 )
103. 103/129
2016
特別篇 5: 黑暗執行緒案例
尋找【 WHERE FlowId = “5b..” 】
IO 次數: 4 ( 完成 )
5b.. cb..
07.. 3b.. 5b.. 9e.. cb..
3 5
1 2 3 4 5
[SeqNo] [FlowId] ...
1 07.. ...
2 9e.. ...
3 3b.. ...
4 cb.. ...
5 5b.. ...
1 3 5 2 4
Nonclustered Index ( 亂序式 )
Clustered Index ( 循序式 )
104. 104/129
2016
特別篇 5: 黑暗執行緒案例
新增【 SeqNo: 6, FlowID: 4c.. 】
IO 次數: 0
5b.. cb..
07.. 3b.. 5b.. 9e.. cb..
3 5
1 2 3 4 5
[SeqNo] [FlowId] ...
1 07.. ...
2 9e.. ...
3 3b.. ...
4 cb.. ...
5 5b.. ...
6 4c.. ...
1 3 5 2 4
Nonclustered Index ( 亂序式 )
Clustered Index ( 循序式 )
105. 105/129
2016
特別篇 5: 黑暗執行緒案例
新增【 SeqNo: 6, FlowID: 4c.. 】
IO 次數: 1
5b.. cb..
07.. 3b.. 5b.. 9e.. cb..
3 5
1 2 3 4 5
[SeqNo] [FlowId] ...
1 07.. ...
2 9e.. ...
3 3b.. ...
4 cb.. ...
5 5b.. ...
6 4c.. ...
1 3 5 2 4
Nonclustered Index ( 亂序式 )
Clustered Index ( 循序式 )
106. 106/129
2016
特別篇 5: 黑暗執行緒案例
新增【 SeqNo: 6, FlowID: 4c.. 】
IO 次數: 2
5b.. cb..
07.. 3b.. 5b.. 9e.. cb..
3 5
1 2 3 4 5
[SeqNo] [FlowId] ...
1 07.. ...
2 9e.. ...
3 3b.. ...
4 cb.. ...
5 5b.. ...
6 4c.. ...
1 3 5 2 4
Nonclustered Index ( 亂序式 )
Clustered Index ( 循序式 )
107. 107/129
2016
特別篇 5: 黑暗執行緒案例
新增【 SeqNo: 6, FlowID: 4c.. 】
IO 次數: 3+3
Page Split 次數: 1
3 5
1 2 3 4 5
[SeqNo] [FlowId] ...
1 07.. ...
2 9e.. ...
3 3b.. ...
4 cb.. ...
5 5b.. ...
6 4c.. ...
Nonclustered Index ( 亂序式 )
Clustered Index ( 循序式 )
07.. 3b.. 4c.. 5b..
1 3 6 5 42
3b.. 5b.. cb..
9e.. cb..
108. 108/129
2016
特別篇 5: 黑暗執行緒案例
新增【 SeqNo: 6, FlowID: 4c.. 】
IO 次數: 3+3+1
Page Split 次數: 1
3 5
1 2 3 4 5
[SeqNo] [FlowId] ...
1 07.. ...
2 9e.. ...
3 3b.. ...
4 cb.. ...
5 5b.. ...
6 4c.. ...
Nonclustered Index ( 亂序式 )
Clustered Index ( 循序式 )
07.. 3b.. 4c.. 5b..
1 3 6 5 42
3b.. 5b.. cb..
9e.. cb..
109. 109/129
2016
特別篇 5: 黑暗執行緒案例
新增【 SeqNo: 6, FlowID: 4c.. 】
IO 次數: 3+3+2
Page Split 次數: 1
3 5
1 2 3 4 5
[SeqNo] [FlowId] ...
1 07.. ...
2 9e.. ...
3 3b.. ...
4 cb.. ...
5 5b.. ...
6 4c.. ...
Nonclustered Index ( 亂序式 )
Clustered Index ( 循序式 )
07.. 3b.. 4c.. 5b..
1 3 6 5 42
3b.. 5b.. cb..
9e.. cb..
110. 110/129
2016
特別篇 5: 黑暗執行緒案例
新增【 SeqNo: 6, FlowID: 4c.. 】
IO 次數: 3+3+3
Page Split 次數: 1
3 5
1 2 3 4 5 6
[SeqNo] [FlowId] ...
1 07.. ...
2 9e.. ...
3 3b.. ...
4 cb.. ...
5 5b.. ...
6 4c.. ...
Nonclustered Index ( 亂序式 )
Clustered Index ( 循序式 )
07.. 3b.. 4c.. 5b..
1 3 6 5 42
3b.. 5b.. cb..
9e.. cb..
111. 111/129
2016
特別篇 5: 黑暗執行緒案例
新增【 SeqNo: 6, FlowID: 4c.. 】
IO 次數: 3+3+4=10 ( 完成 )
Page Split 次數: 1
07.. 3b.. 4c.. 5b..
3 6
1 2 3 4 5 6
[SeqNo] [FlowId] ...
1 07.. ...
2 9e.. ...
3 3b.. ...
4 cb.. ...
5 5b.. ...
6 4c.. ...
1 3 6 5 42
Nonclustered Index ( 亂序式 )
Clustered Index ( 循序式 )
3b.. 5b.. cb..
9e.. cb..
112. 112/129
2016
特別篇 5: 黑暗執行緒案例
如果用一般亂序式 UUID
[FlowId] ... ...
07.. ... ...
9e.. ... ...
3b.. ... ...
cb.. ... ...
5b.. ... ...
5b.. cb..
07.. 3b.. 5b.. 9e.. cb..
Clustered Index ( 亂序式 )
113. 113/129
2016
特別篇 5: 黑暗執行緒案例
尋找【 WHERE FlowId = “5b..” 】
IO 次數: 0
[FlowId] ... ...
07.. ... ...
9e.. ... ...
3b.. ... ...
cb.. ... ...
5b.. ... ...
5b.. cb..
07.. 3b.. 5b.. 9e.. cb..
Clustered Index ( 亂序式 )
114. 114/129
2016
特別篇 5: 黑暗執行緒案例
尋找【 WHERE FlowId = “5b..” 】
IO 次數: 1
[FlowId] ... ...
07.. ... ...
9e.. ... ...
3b.. ... ...
cb.. ... ...
5b.. ... ...
5b.. cb..
07.. 3b.. 5b.. 9e.. cb..
Clustered Index ( 亂序式 )
115. 115/129
2016
特別篇 5: 黑暗執行緒案例
尋找【 WHERE FlowId = “5b..” 】
IO 次數: 2 ( 完成 )
[FlowId] ... ...
07.. ... ...
9e.. ... ...
3b.. ... ...
cb.. ... ...
5b.. ... ...
5b.. cb..
07.. 3b.. 5b.. 9e.. cb..
Clustered Index ( 亂序式 )
116. 116/129
2016
特別篇 5: 黑暗執行緒案例
新增【 FlowID: 4c.. 】
IO 次數: 0
[FlowId] ... ...
07.. ... ...
9e.. ... ...
3b.. ... ...
cb.. ... ...
5b.. ... ...
4c.. ... ...
5b.. cb..
07.. 3b.. 5b.. 9e.. cb..
Clustered Index ( 亂序式 )
117. 117/129
2016
特別篇 5: 黑暗執行緒案例
新增【 FlowID: 4c.. 】
IO 次數: 1
[FlowId] ... ...
07.. ... ...
9e.. ... ...
3b.. ... ...
cb.. ... ...
5b.. ... ...
4c.. ... ...
5b.. cb..
07.. 3b.. 5b.. 9e.. cb..
Clustered Index ( 亂序式 )
118. 118/129
2016
特別篇 5: 黑暗執行緒案例
新增【 FlowID: 4c.. 】
IO 次數: 2
[FlowId] ... ...
07.. ... ...
9e.. ... ...
3b.. ... ...
cb.. ... ...
5b.. ... ...
4c.. ... ...
5b.. cb..
07.. 3b.. 5b.. 9e.. cb..
Clustered Index ( 亂序式 )
119. 119/129
2016
特別篇 5: 黑暗執行緒案例
新增【 FlowID: 4c.. 】
IO 次數: 3+3 ( 完成 )
Page Split 次數: 1
[FlowId] ... ...
07.. ... ...
9e.. ... ...
3b.. ... ...
cb.. ... ...
5b.. ... ...
4c.. ... ...
3b.. 5b.. cb..
07.. 3b.. 4c.. 5b..
Clustered Index ( 亂序式 )
9e.. cb..
121. 121/129
2016
特別篇 5: 黑暗執行緒案例
尋找【 WHERE FlowId = 5 】
IO 次數: 0
[FlowId] ... ...
1 ... ...
2 ... ...
3 ... ...
4 ... ...
5 ... ...
3 5
1 2 3 4 5
Clustered Index ( 循序式 )
122. 122/129
2016
特別篇 5: 黑暗執行緒案例
尋找【 WHERE FlowId = 5 】
IO 次數: 1
[FlowId] ... ...
1 ... ...
2 ... ...
3 ... ...
4 ... ...
5 ... ...
3 5
1 2 3 4 5
Clustered Index ( 循序式 )
123. 123/129
2016
特別篇 5: 黑暗執行緒案例
尋找【 WHERE FlowId = 5 】
IO 次數: 2 ( 完成 )
[FlowId] ... ...
1 ... ...
2 ... ...
3 ... ...
4 ... ...
5 ... ...
3 5
1 2 3 4 5
Clustered Index ( 循序式 )
124. 124/129
2016
特別篇 5: 黑暗執行緒案例
新增【 FlowID: 6 】
IO 次數: 0
[FlowId] ... ...
1 ... ...
2 ... ...
3 ... ...
4 ... ...
5 ... ...
6 ... ...
3 5
1 2 3 4 5
Clustered Index ( 循序式 )
125. 125/129
2016
特別篇 5: 黑暗執行緒案例
新增【 FlowID: 6 】
IO 次數: 1
[FlowId] ... ...
1 ... ...
2 ... ...
3 ... ...
4 ... ...
5 ... ...
6 ... ...
3 5
1 2 3 4 5
Clustered Index ( 循序式 )
126. 126/129
2016
特別篇 5: 黑暗執行緒案例
新增【 FlowID: 6 】
IO 次數: 2
[FlowId] ... ...
1 ... ...
2 ... ...
3 ... ...
4 ... ...
5 ... ...
6 ... ...
3 5
1 2 3 4 5
Clustered Index ( 循序式 )
127. 127/129
2016
特別篇 5: 黑暗執行緒案例
新增【 FlowID: 6 】
IO 次數: 3+1 ( 完成 )
[FlowId] ... ...
1 ... ...
2 ... ...
3 ... ...
4 ... ...
5 ... ...
6 ... ...
3 6
1 2 3 4 5 6
Clustered Index ( 循序式 )