A maneira mais econômica de paginar uma tabela mal ordenada?

Essencialmente, você está perguntando se pode executar uma única varredura ordenada nos dados gerais, sem fazer cópias dos dados e retornar 'x' conjuntos de linhas separados do conjunto completo em cada chamada. Este é exatamente o comportamento de um cursor de API configurado apropriadamente.

Por exemplo, usando a tabela AdventureWorks Person.EmailAddresspara retornar conjuntos de 1.000 linhas:

DECLARE 
    @cur integer,
    -- FAST_FORWARD | AUTO_FETCH | AUTO_CLOSE
    @scrollopt integer = 16 | 8192 | 16384,
    -- READ_ONLY, CHECK_ACCEPTED_OPTS, READ_ONLY_ACCEPTABLE
    @ccopt integer = 1 | 32768 | 65536, 
    @rowcount integer = 1000,
    @rc integer;

-- Open the cursor and return the first 1,000 rows
EXECUTE @rc = sys.sp_cursoropen
    @cur OUTPUT,
    N'
    SELECT *
    FROM AdventureWorks2012.Person.EmailAddress
        WITH (INDEX([IX_EmailAddress_EmailAddress]))
    ORDER BY EmailAddress;
    ',
    @scrollopt OUTPUT,
    @ccopt OUTPUT,
    @rowcount OUTPUT;

IF @rc <> 16 -- FastForward cursor automatically closed
BEGIN
    -- Name the cursor so we can use CURSOR_STATUS
    EXECUTE sys.sp_cursoroption
        @cur, 
        2, 
        'MyCursorName';

    -- Until the cursor auto-closes
    WHILE CURSOR_STATUS('global', 'MyCursorName') = 1
    BEGIN
        EXECUTE sys.sp_cursorfetch
            @cur,
            2,
            0,
            1000;
    END;
END;

Cada operação de busca retorna no máximo 1.000 linhas, lembrando a posição da varredura da chamada anterior.

Sem saber o propósito por trás das janelas, será difícil ser específico. Considerando que você está olhando para vinte mil linhas por vez, imagino que este seja um processo em lote e não para visualização humana.

Se houver um índice no endereço de e-mail, ele será classificado. Os índices são BTrees e mantêm uma ordem internamente. Esta será a ordem de classificação do agrupamento dessa coluna (que é provável, mas não necessariamente, o agrupamento padrão do banco de dados).

Tabelas temporárias - tanto #table quanto @table - estarão presentes em tempdb. Além disso, grandes conjuntos de resultados irão vazar da memória para o tempdb.

Se por "estatísticas" você quer dizer as estatísticas internas do SQL Server que ele mantém em índices ou por meio da create statistics..instrução, não acho que isso funcione. Essas estatísticas têm apenas algumas centenas de baldes (esqueci o limite correto agora) onde você precisará de 39.000 "janelas" para ler sua tabela completa. Se você pretende manter seu próprio mapeamento de linha para janela por meio de gatilhos, isso é possível, mas a sobrecarga pode ser significativa.

A maneira tradicional de percorrer um grande conjunto de dados é lembrando o maior valor de chave de cada grupo e lendo a partir daí. Se a coluna do endereço de e-mail não for exclusiva, ou seja, um endereço pode ocorrer mais de uma vez, você tem algumas opções. A) processe cada lote linha por linha no aplicativo e pule as duplicatas ou b) filtre-as no SQL. "B" exigirá uma classificação, mas se os dados forem lidos na sequência de teclas, essa classificação pode ser otimizada:

declare @MaxKey varchar(255) = '';  -- email size

while exists (select 1 from mytable where address_name > @MyKey)
begin
    ;with NewBatch as
    (
    select top 20000  -- whatever size a "window" must be
        address_name
    from mytable
    where address_name > @MaxKey
    order by address_name
    )
    select distinct
        address_name
    from NewBatch;

    --process and then
    select @MaxKey = max(address_name) -- from this batch of rows
end

A iteração pode acontecer no SQL ou na sua aplicação, dependendo da sua arquitetura.

Se muitas colunas forem necessárias, além do endereço de e-mail, considere um cursor com a palavra-chave KEYSET ou STATIC definida. No entanto, isso ainda usará recursos em tempdb.

Dando um passo para trás, o SSIS foi projetado especificamente para processar grandes conjuntos de linhas com eficiência. Definir um pacote que atenda às suas necessidades pode ser a melhor resposta a longo prazo.

Se você está simplesmente preocupado com a estabilidade da ordem de classificação ao longo do tempo na presença de DML, considere o uso do Snapshot Isolation para consultar a tabela. Você pode deixar uma SNAPSHOTtransação aberta até terminar de extrair as páginas. Isso tem as desvantagens usuais associadas ao Snapshot Isolation.

Dito isso, essa técnica exigirá a classificação de toda a tabela para cada página extraída. Isso é muito caro (desempenho assintótico quadrático).

Considere usar uma tabela temporária com uma IDENTITYchave primária. Dessa forma, você pode facilmente extrair páginas por meio de buscas de intervalo.

As tabelas temporárias não são fixadas na memória. Este é um equívoco comum.

Com 78 milhões de linhas (cada 100 bytes => 7,8 GB de espaço em disco), essa técnica deve funcionar bem.

Observe que extrair os dados da tabela original usando, por exemplo, READ COMMITTEDpode fornecer um conjunto de dados que nunca existiu em nenhum momento (devido ao DML simultâneo). Use SNAPSHOTo isolamento, se puder.

Você pode criar a tabela temporária em seu próprio banco de dados ou em um modo SIMPLE separado, sem backup do banco de dados. Observe também que a classificação de toda a tabela usará temporariamente o máximo de espaço tempdb necessário para armazenar todas as colunas necessárias. Portanto, talvez você precise derivar os números das linhas do índice (exclusivo) já existente (e aplicar o truque de redução de tamanho).

Outra ideia: em vez de armazenar em buffer todas as linhas na tabela temporária, escreva apenas uma chave de cada linha. Você indicou que as buscas na tabela principal seriam rápidas.

Ou você escreve apenas a cada 20.000 linhas para saber por onde começar cada consulta de paginação. A extração de uma página não funcionaria por número de linha, mas com SELECT TOP 20000 ... WHERE SomeKey >= PageStartKey ORDER BY SomeKey.