Início / dba / Perguntas / 325930
Accepted
Borisav Živanović
Asked: 2023-04-13 03:32:49 +0800 CST

A fragmentação do índice clusterizado ocorre no DBMS relacional?

  • 772

É possível que, após um certo padrão de inserções e exclusões aleatórias, os nós de dados de folha se tornem fragmentados com índice clusterizado ?

Ou seja, que a ordem física não reflete a ordem lógica (digamos, chave primária INT) imposta pelo índice clusterizado? Dessa forma, as consultas de intervalo exigiriam E/S aleatória mesmo depois de encontrar o início do intervalo.

A maioria dos cursos universitários (ex. CMU Introduction to Database Systems de Andy Pavlo) diz que os dados são fisicamente ordenados de acordo com a chave. Embora definitivamente aproximado da realidade, isso parece irrealista para mim, considerando o custo da desfragmentação frequente de arquivos que seria necessária.

clustered-index

2 respostas

  1. Best Answer

    SIM

    Você pode criar índices clusterizados em chaves naturais ou em chaves que não são inseridas linearmente. Por exemplo, usando um endereço de e-mail, números de segurança social e outros. Elas são chaves naturais "suficientemente boas" em muitos casos. Ou talvez faça mais sentido ter os dados armazenados fisicamente de forma diferente de um valor de ID. Eu diria que eles ainda NÃO devem ser a chave agrupada, mas faz sentido e é uma maneira de um índice clusterizado se tornar fragmentado.

    Portanto, você pode ficar fragmentado porque uma nova inserção pode estar fora de ordem e gravada no final da árvore quando pertence ao meio.

    Você TAMBÉM pode obter fragmentação de um design de tabela mais típico se tiver exclusões. O cenário é que você tem uma tabela típica com um campo de ID que é incrementado automaticamente. Esta é a melhor escolha prática na maioria das vezes. Você cria o índice clusterizado nesse campo de ID. Tudo bem se tudo o que você fizer for inserir. Todos os novos registros estão no final da árvore e estão ordenados pelo campo ID.

    Mas digamos que você exclua registros.... bem, agora você tem fragmentação porque as páginas de dados não estão cheias. Ou existem páginas anteriormente vazias que não são mais contíguas.

    Nota adicional; você também pode obter fragmentação atualizando um registro. Se você tiver uma coluna criada vazia, mas com largura variável de até 100 caracteres. Quando você volta e atualiza de NULL para um valor, isso pode enviar partes dessa linha para outra página... o que também causa fragmentação.

    • 4

  2. O layout do disco depende do fornecedor.

    Aqui estão algumas informações específicas sobre o InnoDB Engine no MySQL/MariaDB. (Observação: outros fornecedores não seguem necessariamente o mesmo design.)

    • Há sempre uma chave primária.
    • O PK está sempre em cluster e sempre UNIQUE.
    • Os dados são ordenados pelo PK e armazenados em B+Trees em blocos de 16KB.
    • Como diz Jonathan, inserções, exclusões e até mesmo atualizações podem mexer com está em um bloco.
    • Se muitos dados forem colocados em um bloco, ele será dividido em 2 blocos.
    • Alguma tentativa é feita para combinar dois blocos logicamente adjacentes quando eles ficam quase vazios.
    • Eu uso um ID Auto_Increment apenas cerca de 1 vez em 3.
    • Os índices ideais para uma tabela de mapeamento muitos-para-muitos para vincular tabelas Ae Bé PRIMARY KEY(a_id, b_id), INDEX(b_id, a_id). Observe que adicionar um ID a esta tabela degrada o desempenho.
    • Um BTree fragmenta, mas não vale a pena se preocupar. Ele gravita em torno do bloco médio, estando cerca de 69% cheio.
    • O InnoDB não possui um "Número de linha", ao contrário de muitos outros fornecedores.
    • 0

relate perguntas