Andrew Hill's questions

É possível forçar uma consulta a usar uma junção adaptativa? A consulta em questão produz uma junção adaptativa quando executada como SELECT, mas quando executada como SELECT INTO, isso não ocorre.

Eu tenho uma consulta parametrizada que tem uma subconsulta que normalmente seleciona quase nenhuma linha (0 a 4), mas ocasionalmente escolhe 100k.

Acredito que esse seja exatamente o tipo de cenário para o qual uma junção adaptativa foi projetada, mas o SQL Server não escolhe isso como um plano de consulta.

Um plano de consulta de sempre hash-join destrói o servidor, então meu único recurso no momento é forçar a junção a ser loops aninhados e aceitar que solicitações individuais de pior caso levarão alguns segundos extras para serem executadas.

Eu tenho um banco de dados SQL do Azure em compatability 150eBATCH_MODE_ON_ROWSTORE=1

Detalhes adicionais

Por algum motivo, paste-the-plan não acha que o XML para esta consulta é legítimo.

A consulta em questão é:

with
hashes as (select h.[ContactHash]
    FROM HashTable h
        join someTable p on h.id=p.id
    group by [ContactHash]
    having count(distinct key) >1 
        and count(distinct p.thing) between 1 and 20),
dupeContacts as 
    (select distinct c.key,c.ContactHash from someTable c 
    where c.[ContactHash] in (select t.[ContactHash] from hashes t ) and c.key =  @id 
    )
    insert  into @MyTableVar
select * from dupeContacts

As duas tabelas envolvidas são semelhantes a:

HashTable (
    int id ,
    ContactHash varbinary(16)
) -- millions, typically 4:1 to someTable by ID

e

SomeTable (
    int id Primary Key , 
    varchar(100) thing
)

Eu tenho várias tabelas com índices clusterizados no azure PaaS sql server que se tornaram muito maiores que seus dados, com contagem de páginas reservadas várias vezes maior que a quantidade real de dados na tabela. Essas tabelas são apenas inseridas (sem exclusões ou atualizações), embora de tempos em tempos sejam inseridas linhas, que falham na inserção devido à violação de PK.

1. isso é um problema? - o azure está relatando que todo o espaço 'reservado' neste banco de dados está realmente em uso (um pouco esperado pelo que entendo sobre o que significa reservado)
2. existe uma causa conhecida para esta explosão? - uma mesa de 10gb consumindo 70gb de espaço é um pouco excessivo.
3. existe uma maneira de limpar isso?
4. existe uma estratégia que eu possa empregar para evitar que isso aconteça novamente?

um exemplo

partition_id    object_id   index_id    partition_number    in_row_data_page_count  in_row_used_page_count  in_row_reserved_page_count  lob_used_page_count lob_reserved_page_count row_overflow_used_page_count    row_overflow_reserved_page_count    used_page_count reserved_page_count row_count
72057594050904064   274100017   1   1   1082295 1086782 5527998 0   0   0   0   1086782 5527998 61559096

Este é um objeto com fragmentação extrema conhecida (> 90%), no entanto, minha expectativa pessoal é que um layout ruim no disco não cause grandes quantidades de espaço desperdiçado, apenas latência de busca excessiva devido à minimização de leituras contíguas.

Além disso, supondo que as páginas individuais sob inserção aleatória sejam preenchidas e divididas em duas páginas pela metade, cada página deve oscilar entre 50% e 100% (média de 75%), resultando em uma sobrecarga de armazenamento de aproximadamente 25% para uma tabela / tabela altamente fragmentada. índice.

Eu tenho duas mesas:

• Contato (ID, Tipo);

• Endereço (ID).

É possível definir uma chave estrangeira de Endereço (ID,'A') para Contato (ID,Tipo)?

Estou cruzando um ponto com um conjunto de polígonos. A consulta é indexada e os polígonos não se sobrepõem, mas o plano de consulta parece pensar que, em vez de 1 linha, retornarei 18 mil linhas, e isso resulta em um plano de consulta ruim.

Em particular, os nós mais à direita do plano de consulta parecem pensar que a função STPointFromText retornará uma cardinalidade de 1000 e que a interseção desse conjunto de pontos com o índice geométrico retorna 30% das 54k linhas. (executou 1 milhão de pontos na tabela sem encontrar um contra-exemplo que realmente retornasse mais de 1 linha)

O resultado não é horrível nesta consulta abreviada, mas quando eu uno a saída disso em qualquer outra coisa, a estimativa de alta cardinalidade força a tabela upstream a ser um tablescan+hashmap, mesmo que a consulta geral retorne 1 linha. Essa consulta estendida está sendo executada algumas vezes por segundo, então estou me perguntando como posso otimizar isso.

O índice espacial é HHHH, para uma resolução mais alta (aproximadamente 4.000km do lado mais longo do domínio) de aproximadamente 80x50m, existem 56k polígonos no índice, com tamanho mínimo esperado de ~100m.

Observe a diferença entre as linhas est e as reais.

Plano de consulta estimado.