Início / dba / Perguntas / 94222
Accepted
Christopher McGowan
Asked: 2015-03-03 14:03:01 +0800 CST

Tamanho de metadados de linha InnoDB (tamanho mínimo de linha)

  • 772

Estou tentando decidir se devo normalizar mais alguma coisa e preciso saber qual pode ser a menor linha no InnoDB (tenho o MySQL 5.6).

Este não é exatamente o meu caso, mas para simplificar, vamos supor que eu tenha apenas um PK substituto (bigint) e duas colunas TINYINT, nenhuma das quais pode ser nula. Quantos bytes posso esperar que cada linha precise para armazenamento se vou ter 1 bilhão deles?

Eu imagino que cada linha requer alguns metadados (eu sei que requer pelo menos quando há colunas NULLable), mas não consigo encontrar a documentação sobre como calculá-los.

Então, quanto posso esperar ser consumido pelo espaço livre na página e pelos metadados na página (ou isso é tudo junto)?

Eu quero saber para que eu possa julgar melhor quando eu teria uma mesa longa que é estreita o suficiente para evitar a normalização adequada.

mysql innodb

2 respostas

  1. Best Answer

    Cada linha no InnoDB (suponhamos o formato COMPACT) tem estes cabeçalhos:

    • Offsets - um ou dois bytes por campo de tipo de comprimento variável.
    • Flags NULL - um bit por campo NULL, alinhado a um número inteiro de bytes.
    • Os chamados "bytes extras" - um monte de sinalizadores como is_deleted, ponteiro para o próximo registro etc. Cinco bytes em formato COMPACT, fixo.

    Em seguida, vem o(s) campo(s) de chave primária. Em seguida, id de transação de 6 bytes e ponteiro de reversão de 7 bytes. Em seguida, os valores de campo restantes.

    Para a linha fornecida (BIGINT, TINYINT, TINYINT), seu tamanho será:

    • 0 bytes de compensação
    • 0 bytes sinalizadores NULL
    • 5 bytes "Bytes extras"
    • 8 bytes BIGINT
    • 6 bytes trx_id
    • 7 bytes roll_ptr
    • 1 byte TINYINT
    • 1 byte TINYINT

    Portanto, 28 bytes por registro.

    Mas para calcular quanto espaço a mesa vai ocupar você precisa levar em conta:

    • Cabeçalho da PÁGINA (38+56 bytes)
    • trailer da página
    • fator de preenchimento de página
    • registros infinitos, supremos
    • espaço usado por páginas não folheadas

    Verifique estes slides para mais detalhes http://www.slideshare.net/akuzminsky/data-recovery-talk-on-pluk

    • 4

  2. (Estou adicionando uma "resposta", não um comentário por motivos de formatação.)

    @akuzminsky cobriu a maioria das coisas completamente.

    Por que um BIGINT? Um INT UNSIGNED (valor máximo de 4 bilhões) não será suficiente? Isso economizaria 4 GB.

    O fator de preenchimento vem em dois sabores --

    Se as gravações forem feitas corretamente, os blocos estarão 15/16 cheios. O total geral pode ser de 40 a 45 GB

    Se houver INSERTs aleatórios, os blocos estarão em média 69% cheios.

    Agora. vamos perguntar por que esse layout? Os dois TINYINTs serão repetidos muito em um bilhão de linhas. (Em particular, pelo menos 1B/(256*256) = alguns pares serão repetidos pelo menos 4K vezes.) Talvez você possa ter apenas 65K linhas e ter contadores nelas? Talvez alguma outra técnica de resumo funcione para seu aplicativo? (OK, talvez esta mesa seja artificial.)

    BTW, MyISAM levaria 11 GB para os dados dessa tabela (supondo que não haja buracos). Mais outros 15-20 GB para a PRIMARY KEY.

    • 1

relate perguntas