Qual è la differenza tra VARCHAR e CHAR?


366

Qual è la differenza tra VARCHAR e CHAR in MySQL?

Sto cercando di memorizzare gli hash MD5.


15
L'hash MD5 ha sempre 32 caratteri. Pertanto, per massimizzare le prestazioni, utilizzare CHAR (32) poiché CHAR è a lunghezza fissa (vedere le risposte di seguito per maggiori dettagli sulle differenze tra CHAR e VARCHAR).
Augustin,

Risposte:


361

VARCHAR è di lunghezza variabile.

CHAR è a lunghezza fissa.

Se i tuoi contenuti hanno dimensioni fisse, otterrai prestazioni migliori con CHAR.

Vedi la pagina MySQL sui tipi CHAR e VARCHAR per una spiegazione dettagliata (assicurati di leggere anche i commenti).


51
@steven: quando Anon. dice "il contenuto è di dimensioni fisse" significa che le righe della tabella devono contenere tutti i campi di dimensioni fisse. Non si ottiene alcun miglioramento delle prestazioni se si utilizza CHAR su VARCHAR in un campo, ma la tabella contiene altri campi che sono VARCHAR.
Marco Demaio,

2
nessun tipo di dati char aggiunge le prestazioni ... durante l'esecuzione della query sql genererà un piano di esecuzione. Supponiamo che ci siano 2 colonne charcol char (2000) e VarcharCol Varchar (2000). Nel piano di esecuzione, la dimensione della riga stimata per il tipo di colonne varchar potrebbe essere sottovalutata. quindi porta la fuoriuscita a temp db. Quindi usare char è buono per le prestazioni
vignesh

1
qual è il significato del valore in parantesi di VARCHAR (n)?
Sivagami Nambi,

@Marco Demaio conosci il motivo dietro questo?
Dehan de Croos,

1
@ jdc91: per aumentare le prestazioni, l'intera riga deve essere a larghezza fissa. MySQL ottiene il vantaggio di calcolare i requisiti di spazio e offset delle righe in quel tipo di tabella.
Marco Demaio,

225

CHAR

  1. Utilizzato per memorizzare il valore della stringa di caratteri di lunghezza fissa .
  2. Il massimo no. di caratteri che il tipo di dati può contenere è di 255 caratteri .
  3. È più veloce del 50% rispetto a VARCHAR.
  4. Utilizza l'allocazione di memoria statica .

VARCHAR

  1. Utilizzato per memorizzare dati alfanumerici a lunghezza variabile .
  2. Il massimo che questo tipo di dati può contenere è fino a
    • Pre-MySQL 5.0.3: 255 caratteri .
    • Post-MySQL 5.0.3: 65.535 caratteri condivisi per la riga.
  3. È più lento di CHAR.
  4. Utilizza l'allocazione dinamica della memoria .

3
Sono leggermente sorpreso che questa risposta sia stata votata così spesso. La documentazione di MySQL affermaValues in VARCHAR columns are variable-length strings. The length can be specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 5.0.3 and later versions.
DroidOS

2
per non parlare del fatto che è possibile memorizzare anche dati alfanumerici in caratteri
maiuscoli

44
Su cosa si basa questo 50% più veloce? 50% più veloce per fare cosa? In quali condizioni? E cosa intendi per allocazione di memoria statica vs dinamica in questo contesto?
Martin Smith,

4
@MartinSmith stavo per chiedere lo stesso .. non pensare che le informazioni siano accurate. asktom.oracle.com/pls/asktom/…
Ozgur Bar,

2
-1; le affermazioni sulle prestazioni qui sono vaghe e prive di fondamento, la differenza nella strategia di allocazione della memoria (e perché è importante) non è chiarita, e l'affermazione che varchar memorizza "dati alfanumerici" è un po 'strana; le colonne varchar possono sicuramente contenere anche caratteri non alfanumerici!
Mark Amery,

122

CHAR Vs VARCHAR

CHAR viene utilizzato per la variabile Dimensione lunghezza fissa
VARCHAR viene utilizzato per la variabile Dimensione lunghezza variabile.

Per esempio

Create table temp
(City CHAR(10),
Street VARCHAR(10));

Insert into temp
values('Pune','Oxford');

select length(city), length(street) from temp;

L'output sarà

length(City)          Length(street)
10                    6

Conclusione: per utilizzare lo spazio di archiviazione in modo efficiente è necessario utilizzare VARCHAR anziché CHAR se la lunghezza della variabile è variabile


4
Città = char (10), Street = varchar (10), city = Pune, street = Oxford, length (city) = 4, length (street) = 6
abdulwadood

2
questa query (select length (city), length (street) from temp) fornisce il seguente output in mysql 5.7 mysql> select length (city), length (street) from temp; + -------------- + ---------------- + | lunghezza (città) | lunghezza (via) | + -------------- + ---------------- + | 4 | 6 | + -------------- + ---------------- + 1 riga in set (0,00 sec)
Jasbeer Rawal

69

Una CHAR(x)colonna può contenere solo esattamente x caratteri.
Una VARCHAR(x)colonna può contenere fino a x caratteri.

Poiché i tuoi hash MD5 avranno sempre le stesse dimensioni, probabilmente dovresti usare a CHAR.

Tuttavia, non dovresti usare MD5 in primo luogo; ha conosciuto debolezze.
Utilizzare invece SHA2.
Se si utilizzano password di hashing, è necessario utilizzare bcrypt.


44
"Una colonna CHAR (x) può contenere solo esattamente x caratteri.". In realtà, puoi aggiungere dati con meno di x caratteri, ma penso che tu abbia inteso che PRENOTA sempre 10 caratteri di memoria dietro le quinte.
Dan W,

13
Non sai perché stanno memorizzando hash md5, ci sono molte, molte valide ragioni per usare md5 che non hanno nulla a che fare con la sicurezza. Le collisioni non sono affatto comuni e l'algoritmo è più veloce di quelli più sicuri.
John Hunt,

1
Supponendo che la colonna CHAR (x) non imponga esattamente i caratteri x, c'è qualche motivo per usarlo su VARCHAR (x) anche per dati di dimensioni fisse?
NeverEndingQueue

11

Qual è la differenza tra VARCHAR e CHAR in MySQL?

Alle risposte già fornite vorrei aggiungere che nei sistemi OLTP o nei sistemi con aggiornamenti frequenti prendere in considerazione l'utilizzo CHARanche per colonne di dimensioni variabili a causa della possibile VARCHARframmentazione delle colonne durante gli aggiornamenti.

Sto cercando di memorizzare gli hash MD5.

L'hash MD5 non è la scelta migliore se la sicurezza conta davvero. Tuttavia, se utilizzerai una funzione hash, considera invece il BINARYtipo per essa (ad esempio, MD5 produrrà hash a 16 byte, quindi BINARY(16)sarebbe sufficiente invece che CHAR(32)per 32 caratteri che rappresentano cifre esadecimali. Ciò risparmierebbe più spazio e l'efficienza delle prestazioni.


Seguendo questo filo di pensiero, userei CHAR per gli ID aziendali che sono pensati per leggibilità vs efficienza. Userei comunque le chiavi primarie bigint.
Archimede Trajano,

9

Varchar interrompe gli spazi finali se i caratteri inseriti sono più corti della lunghezza dichiarata, mentre il carattere no. Char riempirà gli spazi e sarà sempre la lunghezza dichiarata. In termini di efficienza, varchar è più abile in quanto taglia i caratteri per consentire una maggiore regolazione. Tuttavia, se conosci la lunghezza esatta del carattere, il carattere verrà eseguito con un po 'più di velocità.


7

Nella maggior parte dei RDBMS oggi, sono sinonimi. Tuttavia, per quei sistemi che hanno ancora una distinzione, un campo CHAR viene memorizzato come colonna a larghezza fissa. Se lo definisci come CHAR (10), allora 10 caratteri vengono scritti nella tabella, dove "padding" (in genere spazi) viene utilizzato per riempire qualsiasi spazio che i dati non utilizzano. Ad esempio, il salvataggio di "bob" verrebbe salvato come ("bob" +7 spazi). Una colonna VARCHAR (carattere variabile) è pensata per archiviare i dati senza sprecare lo spazio extra che fa una colonna CHAR.

Come sempre, Wikipedia parla più forte.


5

CHAR è un campo a lunghezza fissa; VARCHAR è un campo di lunghezza variabile. Se stai memorizzando stringhe con una lunghezza variabile selvaggiamente come i nomi, usa un VARCHAR, se la lunghezza è sempre la stessa, usa un CHAR perché è leggermente più efficiente in termini di dimensioni e anche leggermente più veloce.


Mentre suppongo che le affermazioni sulla velocità e l'efficienza di archiviazione qui siano vere, nessuna di esse è confermata in alcun modo (ed è perfettamente plausibile che siano false), il che rende questa risposta non utile; ripete solo ciò che il lettore probabilmente si sarebbe già aspettato essere vero, senza fare nulla per aiutare veramente a confermarlo.
Mark Amery,

1

CHAR è a lunghezza fissa e VARCHAR è a lunghezza variabile. CHAR utilizza sempre la stessa quantità di spazio di archiviazione per voce, mentre VARCHAR utilizza solo la quantità necessaria per memorizzare il testo effettivo.


1

Il carattere è un tipo di dati di carattere a lunghezza fissa, varchar è un tipo di dati di carattere a lunghezza variabile.

Poiché char è un tipo di dati a lunghezza fissa, la dimensione di archiviazione del valore char è uguale alla dimensione massima per questa colonna. Poiché varchar è un tipo di dati a lunghezza variabile, la dimensione di archiviazione del valore varchar è la lunghezza effettiva dei dati immessi, non la dimensione massima per questa colonna.

È possibile utilizzare char quando si prevede che le voci di dati in una colonna abbiano le stesse dimensioni. È possibile utilizzare varchar quando si prevede che le voci di dati in una colonna abbiano dimensioni considerevoli.


0

secondo il libro MySQL ad alte prestazioni :

VARCHAR memorizza stringhe di caratteri a lunghezza variabile ed è il tipo di dati di stringa più comune. Può richiedere meno spazio di archiviazione rispetto ai tipi a lunghezza fissa, poiché utilizza solo lo spazio necessario (ovvero, per memorizzare valori più brevi viene utilizzato meno spazio). L'eccezione è una tabella MyISAM creata con ROW_FORMAT = FIXED, che utilizza una quantità fissa di spazio sul disco per ogni riga e può quindi sprecare spazio. VARCHAR aiuta le prestazioni perché consente di risparmiare spazio.

CHAR ha una lunghezza fissa: MySQL alloca sempre abbastanza spazio per il numero specificato di caratteri. Quando si memorizza un valore CHAR, MySQL rimuove tutti gli spazi finali. (Ciò valeva anche per VARCHAR in MySQL 4.1 e versioni precedenti: CHAR e VAR CHAR erano logicamente identici e differivano solo nel formato di archiviazione.) I valori sono riempiti con spazi come necessario per i confronti.


2
" VARCHAR aiuta le prestazioni perché salva spazio " Risparmia spazio, sì, ma non influisce negativamente sulle prestazioni? VARCHARdeve allocare dinamicamente la memoria come e quando richiesto riducendo così le prestazioni rispetto a CHAR, giusto?
Spikatrix,

@Spikatrix Depends. Se i valori di VARCHAR sono spesso piccoli ma potrebbero arrivare a N byte, l'allocazione dinamica potrebbe risparmiare una notevole quantità di spazio e I / O, che è più performante per molti dati. I valori CHAR di lunghezza approssimativamente uguale sarebbero più performanti. Anche le letture contro le scritture probabilmente fanno la differenza.
Andrew,

-4

Char ha una lunghezza fissa (supporta 2000 caratteri), è l'acronimo di carattere è un tipo di dati

Varchar ha una lunghezza variabile (supporta 4000 caratteri)


-1; questi numeri non sono corretti per MySQL. (Penso che potrebbero essere per Oracle?)
Mark Amery il

-5

Char o varchar: viene utilizzato per inserire dati testuali in cui la lunghezza può essere indicata tra parentesi, ad es. Char (20)


Questo non affronta la domanda originale. OP chiede le differenze pratiche tra i tipi, non la sintassi e lo scopo dei tipi. Inoltre (e )sono parentesi, non parentesi.
maggio

@ 2mac la tua frase finale è vera solo per l'inglese americano; in Gran Bretagna chiamiamo (e )parentesi, e molti inglesi probabilmente non si rendono nemmeno conto che ci sono dialetti dell'inglese in cui la parola "parentesi" può riferirsi a un segno di punteggiatura. C'è un caso forte da fare per preferire le "parentesi" alle "parentesi" - è probabilmente, a conti fatti, l'opzione massimamente chiara quando si prende di mira un pubblico internazionale di programmatori - ma è un caso più complicato delle "parentesi" che si sbagliano.
Mark Amery, il

-11

CHAR:

  • Supporta sia caratteri che numeri.
  • Supporta 2000 caratteri.
  • Lunghezza fissa.

VARCHAR:

  • Supporta sia caratteri che numeri.
  • Supporta 4000 caratteri.
  • Lunghezza variabile.

eventuali commenti ...... !!!!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.