O SQL Server 2019 CTP3.1 introduziu uma otimização para lidar com a contenção de inserção de última página. Isso assume a forma de uma opção de índice chamada OPTIMIZE_FOR_SEQUENTIAL_KEY.
Imagina-se que isso poderia ser uma adaptação de Bw-Tree ou Bz-Tree . No entanto, eles dependem de páginas de tamanho variável, enquanto o mecanismo de armazenamento atual requer páginas de tamanho fixo.
Como a otimização é implementada? Como os algoritmos B-Tree atuais são alterados por essa otimização? Em que circunstâncias eu escolheria não implantar essa opção?
Pesquisar
Uma patente para uma abordagem de chave reversa .
Dei uma olhada rápida usando DBCC PAGE, comparando 2017 com 2019 e 2019 com e sem OPTIMIZE_FOR_SEQUENTIAL_KEY em um índice clusterizado exclusivo para uma coluna int IDENTITY. Não havia nada que obviamente explicasse o novo comportamento. Isso me faz pensar que é uma coisa algorítmica, ao invés de uma coisa estrutural, o que faz sentido.
Uma postagem no blog do MS.
Este recurso parece centrar-se na detecção e prevenção de comboios .
A otimização é implementada aplicando o controle de fluxo nos trabalhadores que tentam inserir para reduzir a contenção pesada e os comboios. A ideia é baseada em um mutex de inserção injusto por agendador e pode ajudar a evitar o acúmulo de lista de espera de travas e comboios como resultado. Quando os usuários optam por índice com a opção, OPTIMIZE_FOR_SEQUENTIAL_KEY, e então fazemos o controle de tráfego/fluxo nos operadores de inserção. Essencialmente, usando um mutex injusto por agendador (em um nível de HoBt em que a otimização está ativada), o controle de fluxo permitirá que apenas um trabalhador por agendador insira o caminho do código de inserção que disputa travas de página, para que possamos reduzir comboios e melhorar a escalabilidade de inserções simultâneas. Pam Lahoud fornece todos esses detalhes em seu bloge não consigo encontrar nada na especificação funcional ou documento de design que indique alterações nos algoritmos atuais da B-Tree. Outras soluções que foram consideradas (uma das quais foi alavancar uma forma otimizada de índices de chave reversa que você mencionou em sua pergunta) têm desvantagens em potencial e a maioria envolveria alterações fundamentais no mecanismo. Essas outras soluções podem ser consideradas no futuro, mas essa solução proporcionou uma melhoria significativa sem alterar fundamentalmente o motor.
Você não gostaria de implantar isso onde não está esperando ou enfrentando contenção de inserção de última página.