Strategia di suddivisione del nodo B-tree in SQL Server per un valore monotonicamente crescente

Considera un indice B-tree su un valore che aumenterà sempre monotonicamente, ad esempio una colonna di tipo IDENTITÀ. Con un'implementazione B-tree convenzionale, ogni volta che un nodo è pieno, sarà diviso il 50% / 50% e finiremo con un B-tree in cui (quasi) tutti i nodi saranno pieni solo del 50%.

So che Oracle scopre quando un valore è in costante aumento e in questi casi Oracle esegue invece una divisione del 90% / 10%. In questo modo, (quasi) tutti i nodi saranno pieni al 90% e si otterrà un utilizzo della pagina molto migliore per questi casi abbastanza comuni.

Non sono stato in grado di trovare la documentazione per una funzionalità simile in SQL Server. Tuttavia, ho eseguito due esperimenti in cui ho inserito rispettivamente N numeri interi casuali e N numeri interi consecutivi in ​​un indice. Il primo caso utilizzava molte più pagine il secondo.

SQL Server offre una funzionalità simile? In tal caso: puoi indicarmi un po 'di documentazione su questa funzione?

AGGIORNAMENTO: dagli esperimenti forniti di seguito, sembra che i nodi foglia siano mantenuti non divisi e i nodi interni siano divisi 50% / 50%. Ciò rende gli alberi B sui tasti crescenti più compatti rispetto ai tasti casuali. Tuttavia, l'approccio del 90% / 10% di Oracle è ancora migliore, e cerco ancora della documentazione ufficiale che possa verificare il comportamento osservato negli esperimenti.

Se sta aggiungendo una riga alla fine dell'indice, assegnerà semplicemente una nuova pagina per la riga anziché dividere la pagina finale corrente. Le prove sperimentali per questo sono di seguito (utilizza la %%physloc%%funzione che richiede SQL Server 2008). Vedi anche la discussione qui .

CREATE TABLE T
(
id int identity(1,1) PRIMARY KEY,
filler char(1000)
)
GO

INSERT INTO T
DEFAULT VALUES
GO 7

GO
SELECT sys.fn_PhysLocFormatter(%%physloc%%)
FROM T

GO

INSERT INTO T
DEFAULT VALUES

GO

SELECT sys.fn_PhysLocFormatter(%%physloc%%)
FROM T
GO

DROP TABLE T

Resi (I risultati possono variare)

(1:173:0) /*File:Page:Slot*/
(1:173:1)
(1:173:2)
(1:173:3)
(1:173:4)
(1:173:5)
(1:173:6)
(1:110:0) /*Final insert is on a new page*/

Questo sembra applicarsi solo ai nodi foglia. Questo può essere visto eseguendo il seguito e regolando il TOPvalore. Per me 622/623era il punto di interruzione tra la richiesta di una e due pagine di primo livello (potrebbe variare se hai abilitato l'isolamento dello snapshot?). Suddivide la pagina in modo equilibrato portando a spreco di spazio a questo livello.

USE tempdb;

CREATE TABLE T2
(
id int identity(1,1) PRIMARY KEY CLUSTERED,
filler char(8000)
)

INSERT INTO T2(filler)
SELECT TOP 622 'A'
FROM master..spt_values v1,  master..spt_values v2

DECLARE @index_info  TABLE
(PageFID  VARCHAR(10), 
  PagePID VARCHAR(10),   
  IAMFID   tinyint, 
  IAMPID  int, 
  ObjectID  int,
  IndexID  tinyint,
  PartitionNumber tinyint,
  PartitionID bigint,
  iam_chain_type  varchar(30),    
  PageType  tinyint, 
  IndexLevel  tinyint,
  NextPageFID  tinyint,
  NextPagePID  int,
  PrevPageFID  tinyint,
  PrevPagePID int, 
  Primary Key (PageFID, PagePID));

INSERT INTO @index_info 
    EXEC ('DBCC IND ( tempdb, T2, -1)'  ); 

DECLARE @DynSQL nvarchar(max) = 'DBCC TRACEON (3604);'
SELECT @DynSQL = @DynSQL + '
DBCC PAGE(tempdb, ' + PageFID + ', ' + PagePID + ', 3); '
FROM @index_info     
WHERE IndexLevel = 1

SET @DynSQL = @DynSQL + '
DBCC TRACEOFF(3604); '

EXEC(@DynSQL)


DROP TABLE T2