Signé ou non signé dans MySQL
Je me demande si l’utilisation du drapeau UNSIGNED a un effet positif sur la définition d’un champ entier dans MySQL. Est-ce que cela rend les requêtes plus rapides ou la base de données plus petite? Ou devrais-je m'en préoccuper uniquement si je suis préoccupé par la limite supérieure?
Selon la section 10.2 du manuel MySQL 5.1:
En mode non strict, quand un la valeur hors limites est assignée à un colonne entière, MySQL stocke la valeur représentant le .__ correspondant. extrémité du type de données de la colonne intervalle. Si vous en stockez 256 dans un TINYINT ou la colonne TINYINT UNSIGNED, MySQL stocke 127 ou 255, respectivement. Quand une colonne à virgule flottante ou à virgule fixe est assigné une valeur qui dépasse le plage impliquée par la précision et l'échelle spécifiées (ou par défaut), MySQL stocke la valeur représentant le point correspondant de cette plage.
Donc, utiliser UNSIGNED n’est vraiment nécessaire que lorsque vous vous préoccupez de la limite supérieure. L'ajout de UNSIGNED n'affecte pas non plus la taille de la colonne, mais le nombre de fois que est représenté .
Peu importe si vous essayez de tirer le meilleur parti de vos valeurs et que vous n’avez pas besoin de valeurs négatives.
Par exemple, supposons que vous vouliez stocker 0-255.
Vous pouvez utiliser un tinyint mais seulement si vous l'utilisez comme non signé.
Beaucoup de bases de données que j'ai vues, les gens ne s'embêtent pas à l'optimisation de ce type et aboutissent à des tables assez volumineuses, car ils utilisent tout le temps des INT.
Néanmoins, si vous parlez d'int vs unsigned int, il n'y a aucun effet sur les performances ni aucun effet d'espace.
D'un point de vue des normes, j'utilise toujours non signé et n'utilise signé que lorsque je sais que j'aurai besoin de valeurs négatives.
En matière de performance ou de stockage, c'est absolument la même chose.
En règle générale, utilisez celle qui vous convient le mieux: si vous n’avez besoin que de valeurs positives, stockez-la comme UNSIGNED, sinon laissez-la être la valeur par défaut [SIGNED].
Un problème se pose lorsqu'une valeur SIGNED est définie pour une colonne PRIMARY AUTOINCREMENT: le comptage des nombres générés automatiquement commence par 1 (pas le plus petit nombre négatif) et les valeurs possibles se termineront plus tôt, car vous n'utiliserez qu'une moitié de valeurs. . Donc, dans ce cas (colonne PRIMARY + AUTOINCREMENT), il est préférable de stocker en tant que UNSIGNED.
Utilisez unsigned lorsque la colonne est uniquement destinée à contenir des nombres positifs.
Cela n'affectera pas les performances d'E/S sur la colonne, car elle occupera toujours exactement la même quantité d'espace.
Cela améliorera la performance, supposons si vous voulez rechercher une quantité <50o.
Sans "unsigned": Déroulement du processus, étant donné que le champ de quantité est un "int" et que vous avez un index de ce champ, MySQL définira la plage entre -2147483648 et 500 et obtiendra le résultat en fonction de cette plage.
Avec "unsigned": Déroulement du processus, puisque le champ quantité est un "int" avec "unsigned" et que vous avez un index de ce champ, MySQL définira la plage de 0 à 500 et obtiendra le résultat en fonction de cette gamme.
Vous pouvez voir ici la documentation MySQL pour les plages de SIGNED vs. UNSIGNED INTs. Vous remarquerez rapidement que le plancher d’un UNSIGNED INT est toujours égal à 0 et qu’il ne peut donc jamais être négatif.
Type Storage Minimum Value Maximum Value
(Bytes) (Signed/Unsigned) (Signed/Unsigned)
TINYINT 1 -128 127
0 255
SMALLINT 2 -32768 32767
0 65535
MEDIUMINT 3 -8388608 8388607
0 16777215
INT 4 -2147483648 2147483647
0 4294967295
BIGINT 8 -9223372036854775808 9223372036854775807
0 18446744073709551615
Warning, il existe un problème avec Unsigned Int (UINT) et Entity Framework ou ADO.NET. Cela pourrait entraîner un problème d’intégration avec MySql Connector version 6.
D'après mon expérience, UInt est lu comme Long par le FE, ce qui peut soulever des problèmes de précision, puisque UInt n'est pas Long. Cela pourrait causer des maux de tête à quiconque ne serait pas au courant du problème.
Autres préoccupations:
Problème d'intégration entre EF et Mysql Connector 6
Je préfère utiliser UNSIGNED SMALLINT (ou MEDIUMINT) plutôt que SIGNED INT . Il enregistre 2 (ou 1) octets , ce qui permet parfois d'obtenir de meilleures performances sur de grands ensembles de données, en particulier avec des colonnes indexées.