Recherche…


Moulage implicite / automatique

select '123' * 2;

Pour faire la multiplication avec 2 MySQL convertit automatiquement la chaîne 123 en un nombre.

Valeur de retour:

246

La conversion en nombre commence de gauche à droite. Si la conversion n'est pas possible, le résultat est 0

select '123ABC' * 2

Valeur de retour:

246

select 'ABC123' * 2

Valeur de retour:

0

VARCHAR (255) - ou non

Max suggéré

Tout d'abord, je mentionnerai quelques chaînes communes qui sont toujours hexadécimales ou limitées à ASCII. Pour ceux-ci, vous devez spécifier CHARACTER SET ascii ( latin1 est ok) pour qu'il ne gaspille pas d'espace:

UUID CHAR(36) CHARACTER SET ascii -- or pack into BINARY(16)
country_code CHAR(2) CHARACTER SET ascii
ip_address CHAR(39) CHARACTER SET ascii -- or pack into BINARY(16)
phone VARCHAR(20) CHARACTER SET ascii -- probably enough to handle extension
postal_code VARCHAR(20) CHARACTER SET ascii -- (not 'zip_code') (don't know the max

city VARCHAR(100) -- This Russian town needs 91:
    Poselok Uchebnogo Khozyaystva Srednego Professionalno-Tekhnicheskoye Uchilishche Nomer Odin
country VARCHAR(50) -- probably enough
name VARCHAR(64) -- probably adequate; more than some government agencies allow

Pourquoi pas simplement 255? Il y a deux raisons d'éviter la pratique courante d'utiliser (255) pour tout.

  • Lorsqu'un SELECT complexe doit créer une table temporaire (pour une sous-requête, UNION , GROUP BY , etc.), le choix préféré consiste à utiliser le moteur MEMORY , qui place les données dans la RAM. Mais les VARCHARs sont transformés en CHAR dans le processus. Cela fait que VARCHAR(255) CHARACTER SET utf8mb4 prend 1020 octets. Cela peut conduire à devoir renverser sur le disque, ce qui est plus lent.
  • Dans certaines situations, InnoDB examinera la taille potentielle des colonnes d'une table et décidera qu'il sera trop gros, abandonnant une CREATE TABLE .

VARCHAR contre TEXTE

Conseils d'utilisation pour *TEXT , CHAR et VARCHAR , ainsi que quelques bonnes pratiques:

  • N'utilisez jamais TINYTEXT .
  • N'utilisez presque jamais CHAR - c'est une longueur fixe; chaque caractère correspond à la longueur maximale du CHARACTER SET (par exemple, 4 octets / caractère pour utf8mb4).
  • Avec CHAR , utilisez CHARACTER SET ascii sauf indication contraire.
  • VARCHAR(n) tronquera n caractères ; TEXT sera tronqué à un certain nombre d' octets . (Mais voulez-vous une troncature?)
  • *TEXT peut ralentir les SELECTs complexes en raison de la gestion des tables temporaires.

INT comme AUTO_INCREMENT

Toute taille de INT peut être utilisée pour AUTO_INCREMENT . UNSIGNED est toujours approprié.

Gardez à l'esprit que certaines opérations "gravent" les identifiants AUTO_INCREMENT . Cela pourrait entraîner un écart inattendu. Exemples: INSERT IGNORE et REPLACE . Ils peuvent pré - allouer un identifiant avant de réaliser que cela ne sera pas nécessaire. Ceci est un comportement attendu et par conception dans le moteur InnoDB et ne devrait pas décourager leur utilisation.

Autres

Il existe déjà une entrée distincte pour "FLOAT, DOUBLE et DECIMAL" et "ENUM". Une seule page sur les types de données est susceptible d'être lourde - Je suggère "Types de champs" (ou devrait-il s'appeler "Types de données"?) Soit une vue d'ensemble, puis divisée en deux pages:

  • Les INT
  • FLOAT, DOUBLE et DECIMAL
  • Strings (CHARs, TEXT, etc.)
  • BINARY et BLOB
  • DATETIME, TIMESTAMP et amis
  • ENUM et SET
  • Données spatiales
  • Type JSON (MySQL 5.7.8+)
  • Comment représenter Money et d'autres «types» courants nécessitant un changement de style dans des types de données existants

Le cas échéant, chaque page de sujet devrait inclure, en plus de la syntaxe et des exemples:

  • Considérations lors de la modification
  • Taille (octets)
  • Contraste avec des moteurs non MySQL (faible priorité)
  • Considérations à prendre en compte lors de l'utilisation du type de données dans une clé principale ou secondaire
  • autre meilleure pratique
  • autres problèmes de performance

(Je suppose que cet "exemple" va se distraire lorsque mes suggestions ont été satisfaites ou ont fait l'objet d'un veto.)

Introduction (numérique)

MySQL propose un certain nombre de types numériques différents. Ceux-ci peuvent être décomposés en

Groupe Les types
Types entiers INTEGER , INT , SMALLINT , TINYINT , MEDIUMINT , BIGINT
Types de points fixes DECIMAL , NUMERIC
Types de virgule flottante FLOAT DOUBLE
Type de valeur de bit BIT

Types entiers

La valeur non signée minimale est toujours 0.

Type Espace de rangement
(Octets)
Valeur minimum
(Signé)
Valeur maximum
(Signé)
Valeur maximum
(Non signé)
TINYINT 1 -2 7
-128
2 7 -1
127
2 8 -1
255
SMALLINT 2 -2 15
-32 768
2 15 -1
32 767
2 16 -1
65 535
MEDIUMINT 3 -2 23
-8,388,608
2 23 -1
8,388,607
2 24 -1
16,777,215
INT 4 -2 31
-2 147 483 648
2 31 -1
2 147 483 647
2 32 -1
4 294 967 295
BIGINT 8 -2 63
-9.223.372.036.854.775.808
2 63 -1
9 223 372 036 854 775 807
2 64 -1
18 446 744 073 709 551 615

Types de points fixes

Les types MySQL DECIMAL et NUMERIC stockent des valeurs de données numériques exactes. Il est recommandé d'utiliser ces types pour conserver une précision exacte, comme pour l'argent.

Décimal

Ces valeurs sont stockées au format binaire. Dans une déclaration de colonne, la précision et l’échelle doivent être spécifiées

La précision représente le nombre de chiffres significatifs stockés pour les valeurs.

L'échelle représente le nombre de chiffres stockés après la décimale

salary DECIMAL(5,2)

5 représente la precision et 2 représente l' scale . Pour cet exemple, la plage de valeurs pouvant être stockée dans cette colonne est -999.99 to 999.99 entre -999.99 to 999.99

Si le paramètre d'échelle est omis, sa valeur par défaut est 0

Ce type de données peut stocker jusqu'à 65 chiffres.

Le nombre d'octets pris par DECIMAL(M,N) est approximativement de M/2 .

Types de virgule flottante

FLOAT et DOUBLE représentent des types de données approximatifs .

Type Espace de rangement Précision Gamme
FLOTTE 4 octets 23 bits significatifs / ~ 7 chiffres décimaux 10 ^ + / - 38
DOUBLE 8 octets 53 bits significatifs / ~ 16 chiffres décimaux 10 ^ + / - 308

REAL est un synonyme de FLOAT . DOUBLE PRECISION est un synonyme de DOUBLE .

Bien que qualifié MySQL permet également (M, D), ne l' utilisez pas. (M, D) signifie que les valeurs peuvent être stockées avec un maximum de M chiffres, où D peut être après la décimale. Les nombres seront arrondis deux fois ou tronqués; Cela causera plus de problèmes que d'avantages.

Étant donné que les valeurs à virgule flottante sont approximatives et ne sont pas stockées en tant que valeurs exactes, les tentatives de les traiter comme exactes dans les comparaisons peuvent entraîner des problèmes. Notez en particulier qu'une valeur FLOAT est rarement égale à une valeur DOUBLE .

Type de valeur de bit

Le type BIT est utile pour stocker les valeurs de champ binaire. BIT(M) permet de stocker jusqu’à M bits, M étant compris entre 1 to 64

Vous pouvez également spécifier des valeurs avec bit value notation de bit value .

b'111'      -> 7
b'10000000' -> 128

Parfois, il est utile d'utiliser «shift» pour construire une valeur à un seul bit, par exemple (1 << 7) pour 128.

La taille maximale combinée de toutes les colonnes BIT d'une table NDB est 4096.

CHAR (n)

CHAR(n) est une chaîne d'une longueur fixe de n caractères . S'il s'agit de CHARACTER SET utf8mb4 , cela signifie qu'il occupe exactement 4*n octets , quel que soit le texte qu'il CHARACTER SET utf8mb4 .

La plupart des cas d'utilisation de CHAR(n) impliquent des chaînes contenant des caractères anglais, par conséquent devraient être CHARACTER SET ascii . ( latin1 fera tout aussi bien.)

country_code CHAR(2) CHARACTER SET ascii,
postal_code  CHAR(6) CHARACTER SET ascii,
uuid    CHAR(39) CHARACTER SET ascii,  -- more discussion elsewhere

DATE, DATETIME, TIMESTAMP, YEAR et TIME

Le type de données DATE comprend la date mais pas de composant temporel. Son format est 'YYYY-MM-DD' avec une plage de «1000-01-01» à «9999-12-31».

Le type DATETIME inclut l'heure au format «AAAA-MM-JJ HH: MM: SS». Il est compris entre '1000-01-01 00:00:00' et '9999-12-31 23:59:59'.

Le type TIMESTAMP est un type entier comprenant la date et l'heure avec une plage effective de '1970-01-01 00:00:01' UTC à '2038-01-19 03:14:07' UTC.

Le type YEAR représente une année et se situe entre 1901 et 2155.

Le type TIME représente une heure au format 'HH: MM: SS' et contient une plage allant de '-838: 59: 59' à '838: 59: 59'.


Exigences de stockage:

|-----------|--------------------|----------------------------------------|
| Data Type | Before MySQL 5.6.4 | as of MySQL 5.6.4                      |
|-----------|--------------------|----------------------------------------|
| YEAR      |      1 byte        |  1 byte                                |
| DATE      |      3 bytes       |  3 bytes                               |
| TIME      |      3 bytes       |  3 bytes + fractional seconds storage  |
| DATETIME  |      8 bytes       |  5 bytes + fractional seconds storage  |
| TIMESTAMP |      4 bytes       |  4 bytes + fractional seconds storage  |
|-----------|--------------------|----------------------------------------|

Fractionsal Seconds (à partir de la version 5.6.4):

|------------------------------|------------------|
| Fractional Seconds Precision | Storage Required |
|------------------------------|------------------|
|              0               |      0 bytes     |
|              1,2             |      1 byte      |
|              3,4             |      2 byte      |
|              5,6             |      3 byte      |
|------------------------------|------------------|

Voir les types de pages DATE, DATETIME et TIMESTAMP , les exigences de stockage des types de données et les fractions de secondes dans les valeurs temporelles du manuel MySQL.



Modified text is an extract of the original Stack Overflow Documentation
Sous licence CC BY-SA 3.0
Non affilié à Stack Overflow