Ho visto in alcuni database di esempio persone che desiderano arrotondare le dimensioni dei campi a un multiplo di un numero di base 2 (ad esempio varchar (32) o varchar (64)) come se stesse offrendo prestazioni migliori o utilizzo dello spazio. C'è qualche vantaggio in questa pratica? O questo è solo il fatto di essere pedante?Devo arrotondare le dimensioni del campo del mio database al multiplo più vicino di un numero di base 2?
Grazie per il lookin
In MySQL, la lunghezza deve essere sempre 255 o 65.535 (a meno che non vi siano motivi specifici per tipo per scegliere una lunghezza diversa). Esistono due modi diversi per memorizzare stringhe di caratteri. Per lunghezze fino a 255, la lunghezza viene memorizzata in un byte anziché in due, salvando un byte di memoria.
In un varchar, la lunghezza è la lunghezza massima. I valori sono memorizzati nella pagina in base alla loro lunghezza effettiva. Pertanto, la lunghezza massima non influisce sulla memorizzazione di nient'altro, ad eccezione delle lunghezze di 1 o 2 byte (a seconda che il massimo sia < = 255 o> = 256). (La lunghezza essendo una potenza di due - ad eccezione di 256 - non ha alcun effetto sullo spazio di archiviazione.)
Come per impostare le lunghezze come potenze di due. Sono colpevole di questo in molte occasioni. È una vecchia abitudine sopportare di voler mantenere i campi allineati sui limiti dei byte. L'idea era di mantenere i campi allineati sui limiti di 4 o 8 byte, perché questo è più ottimale per la CPU (si pensi al linguaggio di programmazione "C"). Questo impediva uno spazio non necessario quando un intero o un valore in virgola mobile richiedeva un allineamento di 4- o 8 byte (quindi alcuni byte sarebbero stati persi) o un sovraccarico non necessario per copiare byte dallo spazio non allineato allo spazio allineato. Naturalmente, come ho appena notato, questa logica non ha basi per i database, perché la lunghezza massima non influisce sulla memorizzazione effettiva sulla pagina.
Un altro motivo per cui questo non ha alcun significato è che il tipo varchar memorizza effettivamente uno o due byte più della lunghezza. Il database si occupa della conversione dal formato fisico della pagina al formato fisico in memoria. Cercare di "ottimizzare" questo processo è molto più impegnativo di quanto valga.
Che ci crediate o meno. Non ci credevo finché non l'ho verificato da solo. Ho creato un database con due campi in due tabelle, entrambi indicizzati, e li ho caricati pieni di dati. Un campo era VARCHAR (100) e l'altro era VARCHAR (256).
Durante l'interrogazione delle tabelle, il campo che era 256 ha ottenuto risultati migliori.
Il motivo per cui questo funziona a causa della dimensione del blocco durante la lettura del disco, corrisponde alla fine e quindi non sta leggendo un blocco parziale alla volta.
Avete qualche prova empirica per confermare questa affermazione? Le pagine di database sono in genere qualcosa come 8192 byte ... E la maggior parte delle pagine dovrebbe essere comunque nella RAM –
@ Mitch, questo era qualche anno fa quindi avrei dovuto ricostruire l'esempio di nuovo, ma potrei essere in grado di arrivare a questo settimana. –
@MitchWheat. . . Questo sarebbe assolutamente corretto, ma non ha nulla a che fare con le potenze di 2. La lunghezza di 256 è la prima lunghezza in cui MySQL utilizza due byte per la lunghezza anziché 1. –
+1. La lunghezza di un campo varchar() dovrebbe fare poca differenza. –
interessante ..hai trovato contatti nella documentazione di mysql o è un'ipotesi educata? –
in realtà preferisco scegliere la lunghezza varchar come x potenza di 2, è più intuitivo per i ragazzi Dev. : / –