Por que o vazamento do TempDB acontece mesmo que as estatísticas estejam corretas?

Como mostra a dica de ferramenta, 7643 páginas de 8 KB são espalhadas = 59,71 MB. O restante da classificação ocorre dentro da memória alocada.

A classificação é derramada por dois motivos:

1. A ordenação é paralela. A estimativa de memória precisa é dividida igualmente entre os threads de classificação e não pode ser realocada dinamicamente entre os threads em tempo de execução. Se as linhas não forem distribuídas uniformemente, um ou mais encadeamentos de classificação poderão ser derramados. Isso é um pouco mais provável de acontecer em baixa DOP, por exemplo, 4 em vez de 8.

2. O SQL Server não leva em conta a sobrecarga de gerenciamento de spill ao estimar o requisito de memória. Isso é detalhado em CORREÇÃO: o operador de classificação transborda para tempdb no SQL Server 2012 ou SQL Server 2014 quando o número estimado de linhas e o tamanho da linha estão corretos.

No SQL Server 2019, a memória concedida entre as execuções pode ser ajustada automaticamente para evitar o spill por meio do mecanismo de feedback de concessão de memória do modo de linha .

Pergunta: Quantos dados são derramados no disco? 400 MB ou 60 MB (7643 KB*8)?

60 MB. Você pode verificar isso despejando

select sum(num_of_bytes_written) / 1024 / 8 approx_pages_written
from sys.dm_io_virtual_file_stats(db_id('TempDb'),null)

antes e depois da consulta

Se tudo está bem com as estimativas, as estatísticas estão atualizadas, a caixa tem memória suficiente e nenhuma consulta estava sendo executada naquele momento, então por que o vazamento no disco acontece?

O tamanho da linha é uma estimativa e a memória precisa ser dividida entre os encadeamentos de varredura paralelos, qualquer um dos quais pode precisar ser derramado.