MVCC はさまざまな方法で実装できます。唯一の要件は、何らかの形で古い行バージョンが利用可能であることです。
たとえば、SQL Server はそれらをサーバーの再起動時にリセットされる一時データベースに格納します。
Postgres は、行バージョンを隠し行として直接 b ツリーに保存します。非表示のキー列をツリーに追加します。ツリーから読み取ると、論理的に表示されるべきバージョンのみが公開されます。
RavenDB の Voron は、b-tree ページを不変データとして管理します。書き込みは、まったく新しいツリーを作成します。したがって、MVCC は正しい不変ツリーからの読み取りとして実装されます。
データベースが長時間にわたって物理構造をロックすることはめったにありません。データベースクライアントがデータベースの内部構造の進行を停止できるようにすることはお勧めできません。通常、内部構造は非常に短時間ロックされます。論理行ロックは個別に処理されます。
私が推測しなければならなかった場合concurrency control on search structuresは、物理的なスレッドセーフを指します。複数のバージョンを管理する必要がないため、これには通常 MVCC は関与しません。短時間のアクセスには、通常のメモリ内ロックで十分です。