Por que a estatística criada automaticamente nesta coluna está vazia?

Consegui reproduzir isso, tanto com uma estatística vazia quanto com uma estatística preenchida. Eu providenciei para que uma estatística automática fosse criada em uma tabela vazia, e o índice foi criado posteriormente:

IF OBJECT_ID(N'dbo.Heap', N'U') IS NOT NULL
BEGIN
    DROP TABLE dbo.Heap;
END;
GO
CREATE TABLE dbo.Heap 
(
    id integer NOT NULL IDENTITY,
    val integer NOT NULL,
);
GO
-- Add 1000 rows
INSERT dbo.Heap
    WITH (TABLOCKX)
    (val)
SELECT
    SV.number
FROM master.dbo.spt_values AS SV
WHERE
    SV.[type] = N'P'
    AND SV.number BETWEEN 1 AND 1000;
GO
SELECT COUNT_BIG(*) 
FROM dbo.Heap AS H
JOIN dbo.Heap AS H2
    ON H2.id = H.id
WHERE H.id > 0
AND H2.id > 0;
GO
-- Empty table
TRUNCATE TABLE dbo.Heap;
GO
-- Repeat exact same query (RT = 500 + 0.2 * 1000 = 700)
GO
SELECT COUNT_BIG(*) 
FROM dbo.Heap AS H
JOIN dbo.Heap AS H2
    ON H2.id = H.id
WHERE H.id > 0
AND H2.id > 0;
GO
-- Add 1000 rows
INSERT dbo.Heap
    WITH (TABLOCKX)
    (val)
SELECT
    SV.number
FROM master.dbo.spt_values AS SV
WHERE
    SV.[type] = N'P'
    AND SV.number BETWEEN 1 AND 1000;
GO
-- Add index
ALTER TABLE dbo.Heap ADD 
    CONSTRAINT [PK dbo.Heap id]
    PRIMARY KEY NONCLUSTERED (id);
GO
SELECT
    S.[name],
    S.auto_created,
    DDSP.stats_id,
    DDSP.last_updated,
    DDSP.[rows],
    DDSP.rows_sampled,
    DDSP.steps,
    DDSP.unfiltered_rows,
    DDSP.modification_counter
FROM sys.stats AS S
CROSS APPLY sys.dm_db_stats_properties(S.[object_id], S.stats_id) AS DDSP
WHERE 
    S.[object_id] = OBJECT_ID(N'dbo.Heap', N'U');

Descobri que as modificações continuam a ser rastreadas com precisão em todas as duplicatas não vazias, mas apenas uma estatística é atualizada automaticamente (independentemente da configuração assíncrona).

As atualizações automáticas de estatísticas ocorrem apenas quando o otimizador de consulta precisa de uma estatística específica e descobre que ela está desatualizada (uma recompilação relacionada à otimização).

O otimizador escolhe entre estatísticas duplicadas, conforme mencionado no documento Plan Caching and Recompilations in SQL Server 2012 :

Um problema não diretamente relacionado ao tópico deste documento é: dadas várias estatísticas no mesmo conjunto de colunas na mesma ordem, como o otimizador de consulta decide quais carregar durante a otimização de consulta? A resposta não é simples, mas o otimizador de consulta usa diretrizes como: Dê preferência a estatísticas recentes sobre estatísticas mais antigas; Dê preferência às estatísticas apuradas por FULLSCANopção às apuradas por amostragem; e assim por diante.

O ponto é que o otimizador escolhe uma das estatísticas duplicadas disponíveis (a "melhor), e essa é atualizada automaticamente se for obsoleta.

Acredito que esta seja uma mudança no comportamento de versões mais antigas - ou pelo menos a documentação sugere que todas as estatísticas desatualizadas de um objeto seriam atualizadas como parte desse processo, mas não tenho ideia de quando isso mudou. Foi certamente depois de agosto de 2013, quando Matt Bowler postou Estatísticas Duplicadas , que contém um repositório prático baseado em AdventureWorks. Esse script agora resulta na atualização de apenas um dos objetos de estatísticas, enquanto na época ambos eram.

A explicação acima corresponde a todos os comportamentos que observei ao tentar reproduzir seu cenário, mas duvido que esteja explicitamente documentado em qualquer lugar. Parece uma otimização sensata, pois há pouco valor em manter as duplicatas totalmente atualizadas.

Isso provavelmente está em um nível de detalhes abaixo do que a Microsoft está disposta a oferecer. Isso também significa que pode mudar sem aviso prévio.