C'è qualche punto nell'usare CHAR se si ha un VARCHAR nella stessa tabella?

Question

Ho appena letto la risposta accettata di this question, che mi ha lasciato questa domanda.

Ecco una citazione da quella risposta:

"Ma dal momento che hai contrassegnato questa domanda con MySQL, citerò una punta MySQL specifico: quando la query genera implicitamente una tabella temporanea, per esempio, mentre l'ordinamento o GROUP BY I campi VARCHAR vengono convertiti in CHAR per ottenere il vantaggio di lavorare con righe a larghezza fissa. Se si utilizzano molti campi VARCHAR(255) per dati che non devono essere così lunghi, ciò può rendere la tabella temporanea molto grande. "

A quanto ho capito, il vantaggio di CHAR è che si ottengono righe a larghezza fissa, quindi non è lo stesso VARCHAR nella stessa mensa? Ci sono dei vantaggi nell'usare CHAR quando hai uno VARCHAR nella stessa tabella?

---

Ecco un esempio:

Tavolo con CHAR:

CREATE TABLE address (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT, 
    street VARCHAR(100) NOT NULL, 
    postcode CHAR(8) NOT NULL, 
    PRIMARY KEY (id) 
); 

tabella senza CHAR:

CREATE TABLE address (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT, 
    street VARCHAR(100) NOT NULL, 
    postcode VARCHAR(8) NOT NULL, 
    PRIMARY KEY (id) 
); 

disposta la tabella con CHAR eseguire una migliore rispetto al tavolo senza CHAR e se sì, in cosa situazioni?

Answer 1

"VARCHAR" stabilisce in genere una lunghezza massima per il campo e memorizza solo i dati inseriti in esso, risparmiando così sullo spazio. Il tipo "CHAR" ha una lunghezza fissa, quindi se si imposta "CHAR(100)", verrà utilizzato 100 caratteri di spazio, indipendentemente dal contenuto.

L'unica volta che si ottiene un vantaggio di velocità è se non si dispone di campi di lunghezza variabile nel record ("VARCHAR", "TEXT", ecc.). È possibile notare che internamente tutti i campi "CHAR" vengono modificati in "VARCHAR" non appena viene aggiunto un tipo di campo di lunghezza variabile, da MySQL.

Anche "CHAR" è meno efficiente dal punto di vista dello spazio, ma più efficiente per la ricerca e l'aggiunta. È più veloce perché il database deve solo leggere un valore di offset per ottenere un record piuttosto che leggere le parti finché non trova la fine di un record. Inoltre, i record di lunghezza fissa ridurranno al minimo la frammentazione, poiché lo spazio dei record eliminato può essere riutilizzato per i nuovi record.

Spero che aiuti.