Mysql
 sql >> Base de données >  >> RDS >> Mysql

Pourquoi la longueur de ligne AVG est-elle 4 fois plus grande que prévu ?

Il existe de nombreuses raisons pour lesquelles la taille moyenne des lignes est élevée.

  • C'est une approximation. (J'ai trouvé qu'il est généralement 2x-3x haut.) Dans un cas extrême - une ligne dans le tableau - il réclamera 16384 octets par ligne. C'est un bloc InnoDB. Le nombre de lignes dans le tableau est estimé . L'espace disque utilisé pour les lignes est exact, mais voir les surcharges ci-dessous. La taille moyenne des lignes est le quotient de ces deux.

  • Surcharge par colonne -- 1 ou 2 octets

  • Surcharge par ligne -- 20-30 octets -- pour gérer les transactions, trouver des lignes dans un bloc, etc.

  • Surcharge par bloc – un certain nombre d'octets par bloc de 16 Ko

  • Frais généraux pour le thrashing dans un BTree - min est d'environ 1/16 d'un bloc, max est d'environ la moitié du bloc, la moyenne est d'environ 30 % après de nombreuses suppressions et/ou insertions aléatoires.

  • Surcharge pour pré-allouer des blocs d'espace disque (1 Mo ? 8 Mo ?)

  • Au fur et à mesure qu'un tableau s'agrandit à partir d'un seul bloc, l'algorithme de mise en page change et le pourcentage de surcharge augmente temporairement.

  • Les lignes supprimées ne restituent pas leur espace au système d'exploitation, de sorte que la taille du fichier reste constante, augmentant ainsi l'apparent taille de ligne.

  • Si vous n'avez pas de PRIMARY KEY explicite ou un UNIQUE clé qui peut être promue en PK, alors il y a un champ inaccessible de 6 octets (par ligne) pour le PK.

  • Grand TEXT /BLOB et même VARCHAR sont stockés "off-record". Cela complique beaucoup les calculs. Et cela dépend de laquelle des 4 ROW_FORMATs vous utilisez. Dans certains cas, il existe un "pointeur" de 20 octets pour chacune de ces cellules.

  • FOREIGN KEY les contraintes n'augmentent pas l'espace requis, sauf qu'elles peuvent forcer la création d'un index.

  • INDEXes , autre que la PRIMARY KEY ne sont pas inclus dans avg_row_length.

  • La PRIMARY KEY habituellement implique très peu de surcharge dans les données BTree. Une simple règle empirique est de 1 % de frais généraux (en haut de la colonne, elle-même). Cette surcharge correspond aux nœuds non feuilles du BTree.

  • Lorsqu'une transaction InnoDB est occupée, toutes les lignes modifiées sont conservées dans la "liste d'historique". Cela entraîne plus de frais généraux.

  • (Pas totalement lié). COMPRESSED d'InnoDB a des problèmes - il ne donne qu'une compression d'environ 2x, contrairement à la compression de texte typique de 3x. Cela coûte un peu de RAM car il faut avoir à la fois les données compressées et non compressées dans le buffer_pool (pour au moins certains blocs).

SHOW TABLE STATUS et récupération depuis information_schema.TABLES donne les mêmes données. Il existe des moyens d'en obtenir certains aperçu de la profondeur du B+Tree pour les données et pour chaque table.