Ce qui est plus rapide: char(1) ou de type tinyint(1) ? Pourquoi?

DE MA PLATE-FORME:

PHP & mySQL

MA SITUATION:

Je suis tombé sur une situation où j'ai besoin de stocker une valeur pour la sélection de l'utilisateur dans l'une de mes colonnes d'une table. Maintenant, mes possibilités:

Soit déclarer la Colonne de type char(1) et de stocker la valeur 'y' ou 'n'
Ou de déclarer la Colonne de type tinyint(1) et de stocker la valeur 1 ou 0
Cette colonne déclarée, peut aussi être indexés pour l'utilisation dans l'application.

MES QUESTIONS:

Donc je voulais savoir laquelle de ces deux types:

Conduit à une accélération de la vitesse des requêtes lorsque cette colonne est accessible (par souci de simplicité, nous allons laisser de côté le mélange d'autres requêtes, ou accéder à d'autres colonnes, s'il vous plaît).
Est le moyen le plus efficace de stocker et d'accéder à des données et pourquoi?
Comment la vitesse d'accès varier si les colonnes sont indexées et quand ils ne le sont pas?

Ma compréhension est que, depuis char(1) et de type tinyint(1), ne représentent que 1 octet de l'espace, de l'espace de stockage ne sera pas un problème dans ce cas. Alors que resterait-est de la vitesse d'accès. Autant que je sache, numérique indexation est plus rapide et plus efficace que n'importe quoi d'autre.
Mais le cas ici est difficile de décider, je pense. Vraiment envie d'entendre votre expérience sur celui-ci.

Vous en remercie d'avance.

Profil et laissez-nous savoir les resoult.
Une fausse dichotomie, il y a aussi enum('1','0') (par exemple).
la question n'a rien à voir avec php, donc j'ai enlevé la balise php
L'indexation d'un champ avec deux valeurs possibles est assez inutile.
Le type de la colonne a peu d'influence sur sa pertinence à des fins d'indexation. Si vous mettez la colonne dans un WHERE clause et il n'y a aucun indice de sa va faire un full table scan quel que soit le type.
WOW! Ne pas s'attendre à ce que cette question serait même vu & a répondu à plusieurs reprises, dans un petit moment. @erenon: Pardon pour mon ignorance, mais comment dois-je faire? Ne phpmyadmin est un outil pour que (je ne sais qui encore) @ricebowl Bonne, mais il y a un truc en elle, comme mentionné par Langdon. Veuillez vous référer à son commentaire. @streetparade: c'est ok, mais regarde comme il a aidé les autres utilisateurs comme Matchu et Zombat pour spécifier un point dans leur commentaire. @récursive je suis d'accord avec Schwern totalement sur ce point. Sur une table avec un million de lignes, un no-index scan serait inutile. Donc, bon à utiliser.

InformationsquelleAutor Devner | 2010-01-07

30

Je pense que vous devriez créer une colonne avec ENUM('n','o'). Mysql magasins de ce type dans des conditions optimales. Il sera également vous aider à stocker uniquement les valeurs autorisées dans le domaine.

Vous pouvez aussi le rendre plus conviviale ENUM('no','yes') sans affecter les performances. Parce que les chaînes de 'no' et 'yes' sont stockés qu'une seule fois par ENUM définition. Mysql stocke uniquement de l'indice de la valeur par ligne.

Aussi la note sur le tri par ENUM colonne:

Les valeurs de l'ENUM sont triés selon l'ordre dans lequel les membres de l'énumération ont été répertoriés dans la spécification de la colonne. (En d'autres termes, les valeurs de l'ENUM sont triés en fonction de leurs numéros d'index.) Par exemple, 'a' trie avant de " b " pour ENUM('a', 'b'), mais " b "trie avant de" a " pour les ENUM('b', 'a').
- Chemin du retour quand, j'ai eu la même question que l'OP, et je comparés à trouver enum la plus rapide et la plus efficace des trois options. Assurez-vous de ne pas utiliser enum('0', '1') comme je l'ai fait, vous finirez par vous demander pourquoi la mise à JOUR X ENSEMBLE Y = 0; ne fonctionne pas (vous avez besoin de guillemets simples).
- +1 pour Langdon. C'est un moment unique que vous avez spécifié. Je ne savais pas à ce sujet jusqu'à maintenant. Cela signifie donc que si nous utilisons le protocole enum('0', '1'), notre requête doit avoir de mise à JOUR de X ENSEMBLE Y = '0'; Est-ce exact? @Ivan Si je suis en droit, ENUM('n','y') prend le même espace que ENUM('non','oui'). Suis-je le droit?
- Oui, l'utilisation de l'espace est le même parce que vous ne pouvez pas ajouter des valeurs de l'autre, puis", " non " et "oui". Mysql stocke uniquement de l'indice de la valeur par ligne, pas la chaîne. Les chaînes de " non " et " oui " sont stockés qu'une seule fois dans la définition de la table.
- Toutes les valeurs de l'enum ont des indices chiffrés, en commençant par 1 (0 est une valeur spéciale pour indiquer la chaîne vide). Vous pouvez utiliser ces indices pour interroger et de définir des valeurs, mais que le manuel dit: "Pour ces raisons, il n'est pas souhaitable de définir un ENUM colonne avec des valeurs d'énumération qui ressemblent à des nombres, parce que cela peut facilement devenir source de confusion." [ dev.mysql.com/doc/refman/5.1/en/enum.html ] (à Ne pas confondre ces indices chiffrés avec de vrais index de colonne, il n'y a tout simplement pas de meilleur mot pour différencier entre eux)
- Les énumérations sont les travaux de la diable!
InformationsquelleAutor Ivan Nevostruev

                       Rate insert tinyint(1) insert char(1) insert enum('y', 'n')
insert tinyint(1)     207/s                --            -1%                  -20%
insert char(1)        210/s                1%             --                  -19%
insert enum('y', 'n') 259/s               25%            23%                    --
Rate insert char(1) insert tinyint(1) insert enum('y', 'n')
insert char(1)        221/s             --               -1%                  -13%
insert tinyint(1)     222/s             1%                --                  -13%
insert enum('y', 'n') 254/s            15%               14%                    --
Rate insert tinyint(1) insert char(1) insert enum('y', 'n')
insert tinyint(1)     234/s                --            -3%                   -5%
insert char(1)        242/s                3%             --                   -2%
insert enum('y', 'n') 248/s                6%             2%                    --
Rate insert enum('y', 'n') insert tinyint(1) insert char(1)
insert enum('y', 'n') 189/s                    --               -6%           -19%
insert tinyint(1)     201/s                    7%                --           -14%
insert char(1)        234/s                   24%               16%             --
Rate insert char(1) insert enum('y', 'n') insert tinyint(1)
insert char(1)        204/s             --                   -4%               -8%
insert enum('y', 'n') 213/s             4%                    --               -4%
insert tinyint(1)     222/s             9%                    4%                --

il semble que, pour la plupart, enum('y', 'n') est plus rapide à insérer dans.

                       Rate select char(1) select tinyint(1) select enum('y', 'n')
select char(1)        188/s             --               -7%                   -8%
select tinyint(1)     203/s             8%                --                   -1%
select enum('y', 'n') 204/s             9%                1%                    --
Rate select char(1) select tinyint(1) select enum('y', 'n')
select char(1)        178/s             --              -25%                  -27%
select tinyint(1)     236/s            33%                --                   -3%
select enum('y', 'n') 244/s            37%                3%                    --
Rate select char(1) select tinyint(1) select enum('y', 'n')
select char(1)        183/s             --              -16%                  -21%
select tinyint(1)     219/s            20%                --                   -6%
select enum('y', 'n') 233/s            27%                6%                    --
Rate select tinyint(1) select char(1) select enum('y', 'n')
select tinyint(1)     217/s                --            -1%                   -4%
select char(1)        221/s                1%             --                   -2%
select enum('y', 'n') 226/s                4%             2%                    --
Rate select char(1) select tinyint(1) select enum('y', 'n')
select char(1)        179/s             --              -14%                  -20%
select tinyint(1)     208/s            17%                --                   -7%
select enum('y', 'n') 224/s            25%                7%                    --

La sélection semble être également à l' enum. Le Code peut être trouvé ici

+1 @gms8994 Merci beaucoup pour les stats. Donne plus de perspicacité dans la vitesse. Est-ce possible pour vous de nous faire savoir si il y a de tout autre outil pour produire les mêmes résultats que ci-dessus? Merci encore.
Il y a aucun de ceux que je connais. J'ai écrit ce one spécialement pour l'utilisation avec cette question, mais vous pouvez vérifier l'GitHub page liée dans la réponse pour elle.
Quelle est la version de mysql avez-vous utilisé?
basée sur le moment où cela a été posté, probable, soit 5.1 ou 5.5 - je ne m'attends pas à un changement significatif dans les pourcentages avec une version plus récente, mais il est tout à fait possible qu'il ait.

InformationsquelleAutor Glen Solsberry

10

À l'aide de tinyint est plus pratique, et vous permettra de plus facilement vérifier la valeur du champ.
```
// Using tinyint 0 and 1, you can do this:
if($row['admin']) {
// user is admin
}
// Using char y and n, you will have to do this:
if($row['admin'] == 'y') {
// user is admin
}
```
Je ne suis pas un expert dans le fonctionnement interne de MySQL, mais il se sent intuitivement que récupération et de tri des champs de type entier est plus rapide que des champs de caractère (j'ai juste le sentiment que 'a' > 'z' est plus de travail que 0 > 1), et semble se sentir beaucoup plus familier à partir d'un calcul de point de vue de 0 et de 1 sont le standard on/off drapeaux. De sorte que le stockage pour les entiers, qui semble mieux, il se sent mieux, et est plus facile à utiliser dans le code de la logique. 0/1 est le gagnant clair pour moi.

Vous pouvez également noter que, dans une certaine mesure, c'est MySQL, la position officielle, ainsi, de leur documentation:

BOOL BOOLÉEN: Ces types sont des synonymes pour
TINYINT(1). Une valeur de zéro est
considérée comme fausse. Des valeurs non nulles sont
considérée comme vraie.

Si MySQL va jusqu'à assimiler TINYINT(1) avec l'opérateur BOOLÉEN, il semble que le chemin à parcourir.
- +1 Une belle façon d'effectuer la vérification lors de l'utilisation de PHP.
- C'est peut-être une bonne chose d'avoir ce type de contrôle? L'IDE, laissez-moi vous expliquer.... require_once("./Permissions.php"); ... if( $row['permissions'] === Autorisations::ADMIN ) { // l'utilisateur est admin } ce n'est pas seulement bon pour la lisibilité du code, à l'aide d'une propriété statique de faire référence à une valeur qui donne un bon moment de la compilation de contre-vérifier les fautes de frappe, et lors de l'utilisation d'un modèle prédictif de l'IDE, il vous aidera code rapidement. Cet exemple vous donne multi-niveau permisions mais je pense que la lisibilité et la maintenabilité est la clé pour le développement de projets à grande échelle, donc je suis pour.
- Merci pour votre commentaire, mais je suis incapable de dire si vous êtes en préconisant l'utilisation de 0 et de 1 ou la non-utilisation de celui-ci. J'ai juste l'impression que votre programmation est différente de la mienne, de sorte s'il vous plaît garder avec moi comme je pourrais prendre un peu plus de temps pour comprendre ce que tu sous-entends.
InformationsquelleAutor Matchu
4

De savoir pour sûr, vous devriez comparer. Ou savez qu'il ne sera probablement pas beaucoup d'importance dans le grand point de vue de l'ensemble du projet.

Les colonnes de type Char ont les codages et les classements, et en les comparant pourrait impliquer inutile bascule entre les encodages, donc j'imagine qu'un int sera plus rapide. Pour la même raison, je pense que la mise à jour d'un index sur une colonne int est également plus rapide. Mais encore une fois, il ne sera pas question beaucoup.

CHAR peut prendre plus d'un octet, selon le jeu de caractères et les options de la table que vous choisissez. Certains personnages peuvent prendre trois octets pour coder, donc MySQL parfois se réserve cet espace, même si vous utilisez uniquement y et n.
- +1 pour le "Mais encore une fois, il ne sera pas question beaucoup." Je suis en train de penser la même chose. La différence est probablement négligeable.
- Ce que vous dites, fait sens pour moi. Donc, dire que si j'utilise enum('n', 'y'), la bascule entre les codages et les comparaisons de lag quand même postuler? Quelle serait la différence lors de l'utilisation de INNODB VS MyISAM?
- Oui, depuis enum colonnes sont définies avec un codage et un classement, je suppose que cela peut avoir un impact sur les performances. Je ne connais pas les différences entre InnoDB et MyISAM, juste une note qui décrit et InnoDB option qui peut affecter char de stockage [ dev.mysql.com/doc/refman/5.1/en/data-size.html ]
InformationsquelleAutor Jan Fabry
2

Ils vont tous deux être si proche qu'il n'a pas d'importance. Si vous vous sentez posez cette question, vous êtes en sur-optimisation. Utilisation selon l'une qui fait le plus de sens logique.
- Merci pour le commentaire.
InformationsquelleAutor Dave Markle
1

Si vous spécifiez les types BOOL ou BOOLEAN comme un type de colonne lors de la création d'une table dans MySQL, il crée le type de colonne comme TINYINT(1). Sans doute c'est le plus rapide des deux.

La Documentation

Aussi:

Nous avons l'intention de mettre en œuvre pleine boolean
type de manipulation, conformément à l'
le standard SQL, dans un avenir MySQL
la libération.
- +1 Merci pour le commentaire et la référence.
InformationsquelleAutor Powerlord
1

Alors que mon intuition est qu'un index sur un TINYINT serait plus rapide qu'un index sur un CHAR(1) en raison du fait qu'il n'existe pas de chaîne de manutention, les frais généraux (classement, d'espaces, etc), je n'ai pas faits pour. Ma conjecture est qu'il n'y a pas une différence de performances significative qui vaut la peine de s'inquiéter.

Cependant, parce que vous êtes à l'aide de PHP, de stockage comme un TINYINT fait beaucoup plus de sens. À l'aide de la 1/0 valeurs est équivalent à l'utilisation de true et false, même quand ils sont retournés comme des chaînes de caractères en PHP, et peuvent être traités comme tels. Vous pouvez simplement faire un if ($record['field']) avec vos résultats sous la forme d'un booléen vérifier, au lieu de convertir entre " y " et " n " de tous les temps.
- +1 @Zombat Qui fait sens. Je pense que l'utilisation des nombres vraiment facilité le traitement avec du code PHP à l'intérieur de l'app.
InformationsquelleAutor zombat

 TINYINT    1 Byte
CHAR(M)     M Bytes, 0 <= M <= 255

est-il différent?

InformationsquelleAutor streetparade

Vous devez vous connecter pour publier un commentaire.