Wird B-Tree beim Löschen von Daten aus der SQL Server-Tabelle mit einem Clustered-Index neu ausgeglichen?

Ich habe eine Tabelle in einer SQL Server-Datenbank mit einem Clustered-Index für den Primärschlüssel. Die Tabelle enthält 1 Million Zeilen. Wenn ich 10K-Zeilen aus der Tabelle lösche, wird der Index während des Löschvorgangs umstrukturiert?

Der Löschvorgang ist Teil der gespeicherten Prozedur. Es kann gleichzeitig mehr als ein Client die gespeicherte Prozedur ausführen. Bei jedem einzelnen Lauf werden jedoch eigene Zeilen gelöscht (die durch den Primärschlüssel eindeutig identifiziert werden). Ich bekomme eine Blockierung der Schlüsselsperre (vom Typ U), wenn mehrere Clients die Prozedur ausführen. Die Blockersperre gehört zu einer Zeile aus derselben Tabelle und ist nicht Teil einer der gleichzeitig ausgeführten Transaktionen. Es sollte keine Blockierung geben, da jeder Lauf versucht, seine eigenen Zeilen zu löschen. Die Eskalation der Sperre findet nicht statt, da sie deaktiviert ist.

Ich vermute, dass der Löschvorgang dazu führen muss, dass der Index neu ausgeglichen wird, und daher kann er während des Umstrukturierungsprozesses eine Schlüsselsperre für jede Zeile der Tabelle vornehmen.

Ich würde mich über jede Meinung dazu sehr freuen.

Um die Frage im Titel zu beantworten, ob der B-Baum während eines Löschvorgangs neu ausgeglichen wurde, scheint die Antwort zumindest im folgenden minimalen Testfall Nein zu sein.

In der folgenden Demo werden Befehle ausgeführt, die am besten für eine Testumgebung geeignet sind.

--create table and fill it
DROP TABLE IF EXISTS bunchesofints
CREATE TABLE bunchesofints (
thisisanint INT PRIMARY KEY CLUSTERED,
junkrow CHAR(1000) NOT NULL
)

INSERT dbo.bunchesofints
SELECT TOP 5000
ROW_NUMBER() OVER(ORDER BY(SELECT NULL)) AS thisisanint,
REPLICATE('a',1000) AS junkrow
FROM sys.all_objects a1
CROSS JOIN sys.all_objects a2


--with this query we can see all the non-leaf pages of the b-tree, plus the IAM
SELECT allocated_page_page_id, page_type_desc, page_level, is_allocated, next_page_page_id, previous_page_page_id
FROM sys.dm_db_database_page_allocations(DB_ID(),OBJECT_ID('dbo.bunchesofints'),NULL,NULL,'DETAILED')
WHERE page_type != 1
GO

--Ok, let's delete most of the rows
;WITH CTE AS (
    SELECT TOP (4500) *
    FROM dbo.bunchesofints
    ORDER BY thisisanint DESC
)

DELETE 
FROM CTE
GO

--Hmm, still have 3 non-leaf index pages
SELECT allocated_page_page_id, page_type_desc, page_level, is_allocated, next_page_page_id, previous_page_page_id
FROM sys.dm_db_database_page_allocations(DB_ID(),OBJECT_ID('dbo.bunchesofints'),NULL,NULL,'DETAILED')
WHERE page_type != 1



--So, where are the rows?
--please note the assumption that your test database has a single file.
DECLARE @firstindexpage INT, @lastindexpage INT, @db INT = DB_ID()
SELECT @firstindexpage = MIN(previous_page_page_id), @lastindexpage = MAX(next_page_page_id)
FROM sys.dm_db_database_page_allocations(DB_ID(),OBJECT_ID('dbo.bunchesofints'),NULL,NULL,'DETAILED')
WHERE page_type = 2 AND page_level = 1

DBCC PAGE(@db,1,@firstindexpage,3) WITH TABLERESULTS
DBCC PAGE(@db,1,@lastindexpage,3) WITH TABLERESULTS

Diese Demo zeigt, dass ein Löschvorgang einen sehr unausgeglichenen B-Baum mit praktisch allen Daten auf einer Seite erzeugen kann.