MySQL char & varchar jeux de caractères & tailles de stockage

Vous demandez-vous à l'espace de stockage occupé par ces deux types de données, comme la documentation de MySQL est légèrement floue sur la question.

CHAR(M) M × w octets, 0 <= M <= 255, où w est le nombre d'octets
requis pour la longueur maximum de caractères dans le jeu de caractères

VARCHAR(M), VARBINARY(M) L + 1 octets si les valeurs de colonne exiger 0 – 255
octets, L + 2 octets si les valeurs peuvent nécessiter plus de 255 octets

Cela semble impliquer pour moi, étant donné qu'un utf8-encodé en base de données, un CHAR sera toujours prendre jusqu'à 32 bits par caractère, tandis qu'un VARCHAR prendra entre 8 et 32 en fonction de la longueur en octets de caractères stockés. Est-ce exact? Ou un VARCHAR implique une 8-bits largeur de caractère, et le stockage multi-octet de caractères UTF8 consomme réellement plusieurs "caractères" de la VARCHAR? Ou ne VARCHAR également toujours stocker 32 bits par caractère? De nombreuses possibilités.

Pas quelque chose que je n'ai jamais eu à s'inquiéter de ce beaucoup avant, mais je suis en train de frapper en mémoire de la table temporaire des limites de taille et je n'ai pas forcément envie d'avoir à augmenter MySQL est disponible à la piscine (pour la deuxième fois).

OriginalL'auteur pospi | 2012-04-10

  1. 9

    CHAR et VARCHAR à la fois les caractères de décompte. Deux d'entre eux comptent au maximum de stockage dont ils pourraient avoir besoin compte tenu de l'encodage des caractères et la longueur. Pour l'ASCII, c'est 1 octet par caractère. Pour l'UTF-8, c'est 3 octets par caractère (et non 4 comme vous le souhaitez, car MySQL est le support de l'Unicode est paralysé pour quelque raison, et il ne supporte pas les caractères Unicode qui aurait besoin de 4 octets en UTF-8). Jusqu'à présent, CHAR et VARCHAR sont les mêmes.

    Maintenant, CHAR juste va de l'avant et se réserve cette quantité de stockage.

    VARCHAR place alloué 1 ou 2 octets, selon que ce maximum de stockage est < 256 ou ≥ 256. Et le montant réel de l'espace occupé par l'entrée est ces un ou deux octets, plus la quantité d'espace réellement occupé par la chaîne.

    Il est intéressant de noter, ce qui rend 85 un nombre magique pour l'UTF-8 VARCHAR:

    • VARCHAR(85) utilise 1 octet pour la longueur, parce que la durée maximale de 85 (paralysé) les caractères UTF-8 est de 3 × 85 = 255.
    • VARCHAR(86) utilise 2 octets pour la longueur, car la longueur maximale possible de 86 (paralysé) les caractères UTF-8 est de 3 × 86 = 258.
    Ajouter à cela, MySQL utf8 de stockage n'est pas seulement paralysé, ce n'est pas votre norme UTF-8. utf8 chaînes codées sont stockés en utilisant à peu près deux fois le stockage de l'ordinaire codé en UTF-8 cordes, ce qui rend encore plus inefficace.
    Je n'étais pas au courant. Avez-vous des détails ou référence à ce sujet?
    Je veux je l'ai fait, mais la documentation n'est pas beaucoup dire à ce sujet. Il y avait une récente question ici à propos de dumping de la base de données où les données ont été sous-évaluées en binaire-comme-est, qui est l'endroit où ceci est très apparent.
    On dirait que c'est plus compliqué que ça. Par exemple, InnoDB a deux différents formats de ligne (COMPACT et REDUNDANT) afin que l'espace occupé par une ligne dépend de qui est en cours d'utilisation. Il n'est plus aussi simple qu'elle l'était autrefois, quand le seul moteur de stockage couramment utilisé a été MyISAM. De toute façon, un 1 octet différence qu'il négligeables de toute façon. Vous êtes plus susceptibles d'être préoccupé par la longueur maximale d'une clé en InnoDB, qui est 768 octets. Donc UTF-8 VARCHAR(256) ne peut faire partie d'une clé. UTF-8 VARCHAR(255) champ être une clé.
    Ah, l'intrigue s'épaissit.. bon à savoir. J'ai aussi remarqué qu'il y est un "utf8mb4" jeu de caractères disponible dans les versions ultérieures de MySQL, qui est un correctif pour le gimped charset utf8 ils avaient été en utilisant jusqu'à ce point.

    OriginalL'auteur Celada