Início / dba / Perguntas / 315537
Accepted
GenGG
Asked: 2022-08-13 04:34:54 +0800 CST

O B-tree no InnoDB usa mark-delete?

  • 772

Aprendi que todas as árvores B secundárias no InnoDB armazenam pares do formulário (chave de pesquisa, TID) onde TID é a chave primária dos registros. Tenho as seguintes perguntas:

(1) No InnoDB, as árvores B secundárias implementam a exclusão por exclusão de marca? Ou seja, as entradas nas folhas são marcadas como exclusão em vez de exclusão física.

(2) Em caso afirmativo, ao inserir uma nova entrada cuja chave de pesquisa é a mesma de alguma entrada excluída por marcação existente, como o InnoDB decide se a entrada excluída por marcação foi confirmada ou não? Por exemplo, suponha que a árvore B seja um índice exclusivo. Suponha que a primeira transação marca-exclui a chave de pesquisa helloe a segunda transação tenta inserir a chave de pesquisa hello. Se a primeira transação ainda não foi confirmada, a inserção deve falhar; caso contrário, a inserção deve ser bem-sucedida. Gostaria de saber como o InnoDB decide se é permitido inserir arquivos hello.

mysql innodb

1 respostas

  1. Best Answer

    Principalmente "não" às suas perguntas.

    Deixe-me examinar vários aspectos de como o InnoDB lida com índices secundários.

    • Eles são armazenados em "B+Trees" (veja Wikipedia), assim como os dados.
    • Os dados B+Tree são ordenados pelo PRIMARY KEY.
    • Cada índice secundário (seja UNIQUE ou não) é armazenado em um B+Tree separado, ordenado pela(s) chave(s) definida(s) no índice.
    • Os BTrees são 16KB (por padrão). Assim, na ordem de 100 dados ou 'linhas' de índice podem ser mantidas em um bloco.
    • Como buscar um bloco (do disco ou localizá-lo no buffer_pool (cf "innodb_buffer_pool_size")) é a maior parte do esforço, não há conceito de 'marcação' para exclusão posterior.
    • UNIQUEas chaves são verificadas no início do processamento da transação; uma duplicata levará a um "tempo limite de espera de bloqueio" ou a um "deadlock" ou "erro de chave duplicada".
    • Índices não-exclusivos são armazenados em cache no "Change Buffer", que é alocado em uma parte (25% por padrão) do buffer_pool. Isso tem uma lista de alterações de índice pendentes (inserir/atualizar/excluir). Eles são coletados, classificados e eventualmente usados ​​para atualizar blocos de índice.
    • O objetivo do buffer de alteração é diminuir a E/S para alterações de índice. Tem o efeito de ser mais eficiente no tratamento de exclusões.
    • Então, de certa forma, o buffer de mudança é como ele 'marca para exclusão'.
    • No BTree de dados, é mantida uma "lista de histórico" de alterações pendentes nos dados. Este é um componente central de como o MVCC funciona e como várias transações podem funcionar com sucesso em vários "modos de isolamento de transações", mesmo quando algumas transações são eventualmente ROLLBACK'd.

    Provavelmente há mais.

    As coisas citadas são tópicos-chave para pesquisa adicional na literatura sobre MySQL.

    • 0

relate perguntas