Digamos que eu tenha uma coluna de tamanho fixo e estou SELECTpartindo dela, digamos 100 linhas. Ao ler diferentes linhas da coluna de comprimento fixo, o SQL Server verifica o comprimento da coluna para cada linha ou verifica uma vez e reutiliza essas informações para que as linhas subsequentes possam ser lidas mais rapidamente?
Por outro lado, para colunas de comprimento variável, o SQL Server precisa verificar o comprimento de cada coluna de comprimento variável para cada linha, usando a matriz de deslocamento.
Portanto, minha pergunta é: o SQL Server verifica o comprimento dos tipos de dados de comprimento fixo para cada linha (ou seja, após os bits de status A e B da linha)? Logicamente, quando ele precisa ler uma coluna de comprimento fixo, ele só precisa verificá-lo uma vez.
Essa sobrecarga é a razão pela qual os índices são melhores em colunas de comprimento fixo?
Não tentando resolver nenhum problema, apenas tentando entender.
Informações extras: em relação a que os índices são melhores em colunas de comprimento fixo: Toda essa questão começou para mim quando eu estava lendo este artigo Estratégias de indexação para desempenho do SQL Server . Em um ponto, ele diz: "Uma chave de índice clusterizado deve ser estreita, mas também usar um tipo de dados de largura fixa". Quais são as razões para esta afirmação? Só consigo pensar no motivo relacionado à minha pergunta, ou seja, colunas de comprimento fixo são mais baratas de ler, porque o comprimento só precisa ser verificado uma vez.
No formato de armazenamento FixedVar , cada coluna de comprimento fixo aparece no mesmo deslocamento em cada linha.
O SQL Server armazena em cache o deslocamento para cada coluna de comprimento fixo necessária e reutiliza essas informações em acessos de linha subsequentes. Ele não calcula o deslocamento novamente para cada linha.
O acesso a dados da parte de comprimento fixo da linha, portanto, tem uma pequena vantagem de eficiência em relação à leitura de dados de comprimento variável. Não é tanto quanto você imagina, porque encontrar dados de comprimento variável envolve apenas algumas instruções extras de CPU em dados que provavelmente já estão no cache L1 (embora não necessariamente na mesma linha).
Você poderá medir uma pequena diferença se testar o acesso a muitos dos mesmos dados em armazenamento fixo versus armazenamento variável. Eu não vi nenhum resultado recente em hardware moderno. Existem outras sobrecargas associadas à execução de consultas no modo de linha em geral que eu esperaria dominar sobre esse efeito.
Em resumo: eu não sairia do meu caminho para escolher tipos de comprimento fixo sobre os de comprimento variável. Escolha um tipo de dados que funcione melhor para o aplicativo em questão.
Um índice secundário de árvore b é uma estrutura separada com uma cópia dos dados indexados classificados de acordo com as chaves de índice. As mesmas considerações gerais mencionadas acima se aplicam à leitura de dados de páginas de índice e de páginas de dados.
Os índices secundários de árvore b devem incluir o localizador de linha (chave(s) de índice clusterizado e possivelmente um exclusivo ). Quando a chave de índice clusterizado inclui um tipo de dados de comprimento variável, quaisquer linhas de índice de árvore b secundárias podem ter sobrecarga extra para o número de colunas de comprimento variável e a matriz de deslocamento de coluna variável. Os índices secundários podem, portanto, ser um pouco mais amplos do que precisam ser. Acredito que esse é o ponto ao qual Paul Randal estava se referindo nessa citação.