[MySQL] Prestazioni di ENUM vs INT

[emanueledg]

In fase di ottimizzazione di un DB, seguendo anche i suggerimenti della funzione PROCEDURE ANALYSE() di MySQL, ho sostituito un campo INT(1) con un ENUM contenente i possibili valori numerici (sono una ventina), ma le prestazioni del DB non sono migliorate, come io mi aspettavo.

Al contrario, il tracking ripetuto conferma che perdo il 20% di potenza.

A quale scopo allora adottare un tipo ENUM anziché un INT?

[piero.mac]

Originariamente inviato da emanueledg
In fase di ottimizzazione di un DB, seguendo anche i suggerimenti della funzione PROCEDURE ANALYSE() di MySQL, ho sostituito un campo INT(1) con un ENUM contenente i possibili valori numerici (sono una ventina), ma le prestazioni del DB non sono migliorate, come io mi aspettavo.

Al contrario, il tracking ripetuto conferma che perdo il 20% di potenza.

A quale scopo allora adottare un tipo ENUM anziché un INT?

Dal manuale ... nota il neretto.

The results show some statistics for the values returned by the query, and propose an optimal data type for the columns. This can be helpful for checking your existing tables, or after importing new data. You may need to try different settings for the arguments so that PROCEDURE ANALYSE() does not suggest the ENUM data type when it is not appropriate.

The arguments are optional and are used as follows:

*

max_elements (default 256) is the maximum number of distinct values that analyse notices per column. This is used by analyse to check whether the optimal data type should be of type ENUM.
*

max_memory (default 8192) is the maximum amount of memory that analyse should allocate per column while trying to find all distinct values.

http://dev.mysql.com/doc/refman/5.0/...e-analyse.html

[Graboid]

Enum accetta, come hai detto tu, solo un certo numero di possibili valori.

Ad un int non puoi far accetare il valore 2 ma il 3 no.

[emanueledg]

Originariamente inviato da piero.mac
You may need to try different settings for the arguments so that PROCEDURE ANALYSE() does not suggest the ENUM data type when it is not appropriate.

ENUM non viene suggerito quando non ritenuto appropriato, quindi viene suggerito solo quando appropriato...

Appropriato in base a cosa? Miglioramento di prestazioni o memoria di massa? Cercando, si scopre che la documentazione ufficiale parla di solo di ottimizzazione di memoria.
Praticamente non posso salvare capra e cavoli, e dovendo migliorare i tempi mi conviene mantenere l'opzione più veloce, cioè INT.

[piero.mac]

Originariamente inviato da emanueledg
ENUM non viene suggerito quando non ritenuto appropriato, quindi viene suggerito solo quando appropriato...

Appropriato in base a cosa? Miglioramento di prestazioni o memoria di massa? Cercando, si scopre che la documentazione ufficiale parla di solo di ottimizzazione di memoria.
Praticamente non posso salvare capra e cavoli, e dovendo migliorare i tempi mi conviene mantenere l'opzione più veloce, cioè INT.

a me pare di capire diversamente nel manuale.

You may need to try different settings for the arguments so that PROCEDURE ANALYSE() does not suggest the ENUM data type when it is not appropriate.

Potrebbe essere necessario provare diverse impostazioni per gli argomenti in modo che PROCEDURE ANALYSE() non suggerisca l'ENUM come tipo di dati quando questo non è appropriato.

se lo provo su una tabella in modo generico mi suggerisce enum anche per le date ed i timestamp. Non credo sia una cosa cosi' utile. Bisognerebbe crearsi la propria procedura.

Anche perche' con un tinyint che occupa un byte e mi tiene 255 valori mi pare proprio inutile utilizzare un enum.

prova a passare un parametro all'analyze. se fai un campo INT per 20 valori ... ti dice enum. ma se il campo e tinyint ti dira' che va bene. Almeno credo.

[emanueledg]

Originariamente inviato da Graboid
Enum accetta, come hai detto tu, solo un certo numero di possibili valori.

Ad un int non puoi far accetare il valore 2 ma il 3 no.

È chiaro, quella è la distinzione concettuale tra i tipi ENUM e INT.

Il valore da immagazzinare non proviene da un campo utente ad inserimento libero, ma da un menu select, inoltre come il buon senso vuole, c'è un livello di astrazione tra il valore ricevuto dalla select e il valore che l'applicazione inserisce nel DB.

La cosa che mi interessava capire era se si parlasse di ottimizzazione di prestazioni oppure di ottimizzazione di memoria (che spesso corrisponde anche ad un'ottimizzazione di prestazioni, ma in questo caso non è così).

[piero.mac]

Originariamente inviato da emanueledg
La cosa che mi interessava capire era se si parlasse di ottimizzazione di prestazioni oppure di ottimizzazione di memoria (che spesso corrisponde anche ad un'ottimizzazione di prestazioni, ma in questo caso non è così).

Credo si tratti di campo appropriato ai dati inseriti.

se hai voglia guarda qui e per il 5.1 ma non cambia granche' come risultato:

http://dev.mysql.com/sources/doxygen...cc-source.html

[emanueledg]

Originariamente inviato da piero.mac
a me pare di capire diversamente nel manuale.


se lo provo su una tabella in modo generico mi suggerisce enum anche per le date ed i timestamp. Non credo sia una cosa cosi' utile. Bisognerebbe crearsi la propria procedura.

Anche perche' con un tinyint che occupa un byte e mi tiene 255 valori mi pare proprio inutile utilizzare un enum.

prova a passare un parametro all'analyze. se fai un campo INT per 20 valori ... ti dice enum. ma se il campo e tinyint ti dira' che va bene. Almeno credo.

Hai ragione, ho tralasciato la prima parte della frase.

Però se il funzionamento di procedure analyse() è quello e richiede a sua volta delle prove, allora una prova empirica è più efficace, o almeno più rapida: ho provato i vari tipi sui campi interessati e fatto un tracking sulle query da ottimizzare, vedendo direttamente i risultati.

[piero.mac]

Originariamente inviato da emanueledg
Hai ragione, ho tralasciato la prima parte della frase.

Però se il funzionamento di procedure analyse() è quello e richiede a sua volta delle prove, allora una prova empirica è più efficace, o almeno più rapida: ho provato i vari tipi sui campi interessati e fatto un tracking sulle query da ottimizzare, vedendo direttamente i risultati.

Secondo me dice pure quando potrebbe essere utile. Per esempio quando importi dati e non hai idea di come dovrebbe essere la lunghezza dei campi per i dati che ricevi.

Dopo che hai importato (parliamo di migliaia di record) con analyse vedi la lunghezza min/max dei campi ed il tipo corretto di campo da applicare. Ma se i dati sono pochi e/o ripetitivi ti suggerisce enum perche' viene facilitata la ricerca, anche se spesso e' un suggerimento del belino a vela. Come per le date per esempio.

[emanueledg]

Originariamente inviato da piero.mac
Secondo me dice pure quando potrebbe essere utile. Per esempio quando importi dati e non hai idea di come dovrebbe essere la lunghezza dei campi per i dati che ricevi.

Dopo che hai importato (parliamo di migliaia di record) con analyse vedi la lunghezza min/max dei campi ed il tipo corretto di campo da applicare. Ma se i dati sono pochi e/o ripetitivi ti suggerisce enum perche' viene facilitata la ricerca, anche se spesso e' un suggerimento del belino a vela. Come per le date per esempio.

Sì, credo di essere già nella condizione ottimale perché ho lanciato quella funzione in un production environment, una tabella da qualche centinaio di migliaia di record, (già precedentemente ottimizzata) sono sull'ordine di un centinaio di MB e ci sono tutti i possibili valori.

Allo zend workshop mi sono consultato con altri e non ero il solo a pensare che l'ottimizzazione di memoria portasse anche miglioramento nelle prestazioni. Qualcuno mi ha suggerito di usarlo come indice, ma non posso sprecarli perché sono già sui campi fondamentali per le ricerche. Una tabella con tutti (o quasi) i campi indicizzati è come una tabella senza indici...

P.S.: che è il "belino a vela"???