IN-Memory OLTP of Range Index using BW-tree structure similar to the B-tree,
Range and effectively improve the efficiency point search through BW-tree, and save even more memory overhead,
In particular, more suitable for DATE, DATETIME and DATETIME2.
I've written an Bw (Buzz Word) - Tree note, this I add details and concepts previously overlooked
Bw-Tree advantage
1. For range (range) and pointer (point) has a very efficient search
2. homeostatic
3. Each logical page through another pointer to string together
4. Key in accordance with a sequential access
The more efficient use of multi-CPU
BW-tree structure is as follows
When I send where c1 = 13 and using range index search, will start PID0 start and know the next page to be used PID1 (since 8 to 30),
Then PID1 will provide PA through PMT, through the PA we know PID13 have the data we need,
Since PID13 is already a leaf page level, so the page will provide real data memory address,
And then In-Memory OLTP engine knows to search the page already conform to the required data users.
If C1 is repeated more than pen
These data will be repeated again with Linked (similar hash indexes),
Because the leaf page will not contain duplicate row head
Data Update
If I were the original 13 update (update) 15, in order to improve transaction efficiency, in-Memory OLTP engine will no longer update the original page,
But to create (insert) a smaller page contains data change information on the last update PMT corresponding to the PA and point to real data was last updated,
Since the entire BW-tree access path does not change, so the more you can save memory overhead,
It has been marked to delete old data, follow-up by the GC automatic recovery.
reference
Bw (Buzz Word) - Tree Notes
In-Memory OLTP – ORDER BY Behavior Clause Using Range Index
LOB and Row-Overflow Storage in In-Memory OLTP in SQL Server 2016
In-Memory OLTP – Row Structure and Indexes
In-Memory OLTP: Part 2 – Indexes
原文:大专栏 [SQL Server] Range Index