メモリ内のBツリーに似たBW-ツリー構造を使用して範囲指数のOLTP、
範囲と効果的BW-ツリーを効率点の探索を改善し、さらに多くのメモリのオーバーヘッドを節約します、
具体的には、DATEに適し、DATETIMEおよびDATETIME2。
これは私が以前に見落とさ詳細や概念を追加し、ツリーノート - 私は、BW（バズWordを）書きました
BW-ツリー利点
範囲（レンジ）とポインタ（点）1.は非常に効率的な検索を有し
2.恒常性
3.一緒に文字列に別のポインタを通じて各論理ページ
シーケンシャルアクセスに従い4.キー
マルチCPUをより効率的に使用
次のようにBW-ツリー構造があります
私はここで、C1 = 13と範囲インデックス検索を使用して送信すると、PID0（8〜30以降）PID1使用する次のページを開始し、知っているが開始されます
その後PID1は、PAを通して我々はPID13は我々が必要とするデータを持って知って、PMTを通じてPAを提供します
PID13はすでにリーフページレベルであり、そのページには、実際のデータ・メモリ・アドレスを提供しますので、
そして、インメモリOLTPエンジンに必要なデータをユーザーに適合し、既にページを検索するために知っています。
C1は、ペン以上繰り返された場合
これらのデータは、リンクされた（同様のハッシュインデックス）で再び繰り返されます
リーフページには、重複行ヘッドは含まれませんので
データ更新
私は、元の13のアップデート（更新）15だった場合は、トランザクション効率を向上させるためには、インメモリOLTPエンジンは、もはや元のページを更新しません、
しかし、（挿入）を作成するために、小さいページは、PAとポイント最後に更新された実際のデータに対応する最終更新PMTのデータ変更情報が含まれています
全体BW-treeアクセスパスが変更されないので、より多くのあなたは、メモリのオーバーヘッドを保存することができますので、
GC自動回復によってフォローアップ、古いデータを削除するようにマークされています。
参照
BW（バズワード） - ツリーの注意事項
インメモリOLTP - レンジインデックスを使用して行動ORDER BY節
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