Evolution de MySql haute performance (2) : optimisation des types de données_Partie 2

· BLOB/TEXT
Dans les applications réelles, il est souvent nécessaire de stocker deux types de données plus volumineuses, par exemple une image de 10 M, et l'autre est un texte plus grand, par exemple un article de dizaines de milliers. de mots. Dans Oracle, il existe BOLB et CLOB pour traiter ces deux types de données, tandis que dans MySQL ils correspondent à BLOB et TEXT
Compte tenu de la particularité de ces deux types de données, le stockage et le fonctionnement de BLOB et TEXT sont. effectué dans MySQL. Traitement spécial :
1) Les valeurs BLOB/TEXT sont souvent traitées comme des objets. Ces objets ont leurs propres identifiants et espaces de stockage indépendants
2) Lorsque les valeurs BLOB/TEXT sont utilisées pour le tri. , seuls les N premiers octets seront utilisés, N correspond à une valeur constante dans la base de données (max_sort_length), si vous souhaitez spécifier plus d'octets à utiliser pour le tri, alors vous pouvez augmenter la valeur de max_sort_length ou utiliser ORDER BY SUBSTRING( column, length) fonction à gérer
3) Lorsque BLOB/TEXT est utilisé pour l'indexation ou le tri, la valeur du champ entier ne peut pas être utilisée
Évitez d'utiliser BOLB/TEXT en dernier recours pour l'indexation ou le tri
Étant donné que le moteur de mémoire de MySQL ne prend pas en charge les types BLOB et TEXT, si BLOB /TEXT est impliqué dans le processus de requête, vous devez utiliser une table temporaire du disque MyISAM, même s'il n'y a que quelques lignes de données. true (le moteur de mémoire du dernier serveur Percona prend en charge les types BLOB et TEXT).

L'accès fréquent du moteur de mémoire aux tables temporaires du disque entraînera une importante surcharge de performances. La meilleure solution est d'éviter autant que possible d'utiliser les types BLOB et TEXT. Si vous ne pouvez pas l'éviter, une astuce consiste à utiliser SUBSTRING(column, length) partout où un champ BLOB est utilisé pour convertir la valeur de la colonne en chaîne (fonctionne également dans la clause ORDER BY), afin que vous puissiez utiliser un in -tableau temporaire de mémoire. Cependant, assurez-vous que la sous-chaîne interceptée est suffisamment courte pour que la taille de la table temporaire ne dépasse pas max_heap_table_size ou tmp_table_size. Après avoir dépassé la limite, MySQL convertira la table temporaire de mémoire en table temporaire de disque MyISAM.

L'allocation de longueur dans le pire des cas est également la même pour le tri, cette astuce est donc utile pour créer de grandes tables temporaires et trier des fichiers en mémoire, et créer de grandes tables temporaires sur disque et fichier. le tri est utile dans les deux cas. Par exemple, supposons que vous disposiez d’une table de 10 millions de lignes qui occupe plusieurs gigaoctets d’espace disque. Il existe une colonne VARCHAR(1000) avec le jeu de caractères utf8. Chaque caractère utilise jusqu'à 3 octets, ce qui nécessite 3 000 octets d'espace dans le pire des cas. Si cette colonne est utilisée dans ORDER BY et que la requête analyse la table entière, plus de 30 Go de tables temporaires seront nécessaires pour le tri

·     DATETIME/TIMESTAMP

MySQL contient deux formats d'heure DATETIME et TIMESTAMP, généralement la différence entre les deux types n'est pas très grande lors de l'utilisation, mais il y a quand même des différences dans les détails

Comme TMESSTAMP prend moins d'espace de stockage, il peut être utilisé Il sert de le format d'heure par défaut

· ENUM

Ce type de champ enregistre principalement les valeurs des colonnes​​par énumération, car il sera impliqué dans le processus d'utilisation La conversion entre le la position de l'énumération et la valeur réelle peuvent avoir un certain impact sur les performances globales, et la valeur de l'énumération est stockée dans .frm (fichier de définition de structure de table de données), donc après la création de la colonne ENUM, si vous souhaitez mettre à jour le contenu de EMUM, cela équivaut à mettre à jour la structure des tables.
Ce qui suit est un exemple simple de création d'une colonne ENUM :

mysql> CREATE TABLEenum_test(
->  e ENUM('fish', 'apple', 'dog') NOT NULL
-> );
mysql> INSERT INTOenum_test(e) VALUES('fish'), ('dog'), ('apple');

·                                                                                                                                                               Les champs nécessitent le moins d'espace, comment feriez-vous le concevoir ? Utiliser INT ou CHAR(1) ? Comparé à INT et CHAR(1), BIT(1) peut être un meilleur choix car il ne prend qu'un seul BIT. Il peut exprimer les valeurs de plusieurs BIT sous la forme de BIT(N), qui prend en charge jusqu'à BIT(64).

Dans les versions antérieures à MySQL 5.0, BIT était considéré comme équivalent à TINYINT, mais dans la nouvelle version, il est traité comme deux types complètement différents.

Lorsque vous récupérez un champ BIT de la base de données et que vous l'affichez sur la console, la valeur sera affichée en codage ASCII. Lorsque la valeur du champ apparaît dans le cadre d'une opération numérique, elle sera traitée. comme La valeur décimale de BIT. L'exemple suivant peut clairement illustrer ces deux situations

L'exemple ci-dessus peut vous dérouter, et il est très probable que vous ne souhaitiez plus utiliser ce mécanisme pour. stocker un seul bit. Comme alternative, vous pouvez définir le champ correspondant sur CHAR(0), NULL est utilisé pour représenter False, "" (Chaîne vide) représente True

mysql>CREATE TABLE bittest(a bit(8));
mysql> INSERT INTObittest VALUES(b'00111001');
mysql> SELECT a, a+ 0 FROM bittest;
+------+-------+
| a | a + 0 |
+------+-------+
| 9 | 57 |
+------+-------+

Ce qui précède est l'évolution de high-. performances MySql ( 2) : Contenu sous Data Type Optimization_, pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !