Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 11
  1. #1
    Utente di HTML.it L'avatar di /dev/null
    Registrato dal
    May 2004
    Messaggi
    1,936

    Ottimizzare database MySQL

    Ho alcune domande riguardo le prestazioni dei db mysql...
    Ho gia' letto il thread linkato in rilievo, ma non mi e' bastato...

    In un db devo tenere degli uteni... I cui nomi possno raggiungere al massimo i 24 caratteri...
    Mi conviene usare un tipo di dato statico o uno dinamico?

    Seconda cosa: UNIQUE rallenta, velocizza o non muta, da questo punto di vista il db?


    Sapete inoltre darmi qualche link dove trattino le prestazioni di mysql?

    Ultima modifica ad opera dell'utente /dev/null il 01-01-0001 alle 00:00

  2. #2
    unique ovviamente accellera le ricerche, e come ogni indice, rallenta update, delete e insert ^^

    dipende quali, in quantità, esegui di +, il mettere o meno un indice ^^
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  3. #3
    Utente di HTML.it L'avatar di /dev/null
    Registrato dal
    May 2004
    Messaggi
    1,936
    Gia'
    Ma non esiste qualche documentazione dalla quale capire come gestire gli indici, quanti farne e perche' etc?
    Ultima modifica ad opera dell'utente /dev/null il 01-01-0001 alle 00:00

  4. #4
    Originariamente inviato da /dev/null
    Gia'
    Ma non esiste qualche documentazione dalla quale capire come gestire gli indici, quanti farne e perche' etc?
    Non piu' di quanta documentazione potresti trovare per il for od il while. Nel senso che non esiste una regola generale. Di solito si fa un indice per le query select piu' frequenti. Un indice e' un elenco ordinato dei record. Se ti scosti come richiesta dall'impostazione data, non verra' usato e quindi non servirebbe.

    Se devi inserire, aggiornare, cancellare deve anche inserire ecc.. nell'indice, quindi per es. tre indici significa 3 manipolazioni di dati. In pratica in una agenda se cerchi per cognome e nome ed hai fatto un indice composto da questi due campi, il db non va a cercare i record nella tabella per poi ordinarli ma li prendera' direttamente dall'indice e quindi l'operazione di estrazione sara' notevolmente accelerata. Il tempo lo perde al momento dell'insert, perche' deve riordinare l'indice con i nuovi dati inseriti.

    Ora se tu fai 1000 letture ed 10 inserimenti il vantaggio e' notevole. sei invece penalizzato nel caso contrario, 1000 inserimenti e 10 letture. come vedi dipende dall'applicazione.


    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  5. #5

    Re: Ottimizzare database MySQL

    Originariamente inviato da /dev/null
    In un db devo tenere degli uteni... I cui nomi possno raggiungere al massimo i 24 caratteri...
    Mi conviene usare un tipo di dato statico o uno dinamico?
    In realtà non basta che il singolo campo sia a dimensione fissa per velocizzare l'accesso alla tabella. Deve essere l'intera riga a dimensione fissa.

  6. #6
    Utente di HTML.it L'avatar di /dev/null
    Registrato dal
    May 2004
    Messaggi
    1,936
    Originariamente inviato da piero.mac
    Non piu' di quanta documentazione potresti trovare per il for od il while. Nel senso che non esiste una regola generale. Di solito si fa un indice per le query select piu' frequenti. Un indice e' un elenco ordinato dei record. Se ti scosti come richiesta dall'impostazione data, non verra' usato e quindi non servirebbe.

    Se devi inserire, aggiornare, cancellare deve anche inserire ecc.. nell'indice, quindi per es. tre indici significa 3 manipolazioni di dati. In pratica in una agenda se cerchi per cognome e nome ed hai fatto un indice composto da questi due campi, il db non va a cercare i record nella tabella per poi ordinarli ma li prendera' direttamente dall'indice e quindi l'operazione di estrazione sara' notevolmente accelerata. Il tempo lo perde al momento dell'insert, perche' deve riordinare l'indice con i nuovi dati inseriti.

    Ora se tu fai 1000 letture ed 10 inserimenti il vantaggio e' notevole. sei invece penalizzato nel caso contrario, 1000 inserimenti e 10 letture. come vedi dipende dall'applicazione.

    Capit
    Uhm... E sai dirmi dove posso trovare una descrizione/elenco di tutti i vari indici esistenti? Conosco ancora troppo poco (my)SQL...










    Originariamente inviato da Gianni_T
    In realtà non basta che il singolo campo sia a dimensione fissa per velocizzare l'accesso alla tabella. Deve essere l'intera riga a dimensione fissa.
    Quindi se TUTTI i campi dal primo all'ultimo sono stringhe con dimensione variabile, oppure se c'e' soltanto un campo a dimensione variabile le prestazioni sono le stesse?





    Grazie a tutti per ora

    Ultima modifica ad opera dell'utente /dev/null il 01-01-0001 alle 00:00

  7. #7
    Originariamente inviato da /dev/null
    Quindi se TUTTI i campi dal primo all'ultimo sono stringhe con dimensione variabile, oppure se c'e' soltanto un campo a dimensione variabile le prestazioni sono le stesse?
    per convincertene guarda come MySQL si comporta se crei una tagella così:
    codice:
    CREATE TABLE `table1` (                                                                                                                                                                         
              `id` int(11) NOT NULL default '0',                                                                                                                                                            
              `str1` char(10) default NULL,                                                                                                                                                                 
              `str2` char(15) default NULL,                                                                                                                                                                 
              `str3` varchar(20) default NULL,                                                                                                                                                                 
              PRIMARY KEY  (`id`)                                                                                                                                                                           
            ) TYPE=MyISAM
    dopo aver creato la tabella vai a vedere come mysql l'ha realmente memorizzata...sorpresa! tutti i campi char sono diventati varchar!

  8. #8
    Utente di HTML.it L'avatar di /dev/null
    Registrato dal
    May 2004
    Messaggi
    1,936
    Originariamente inviato da Gianni_T
    per convincertene guarda come MySQL si comporta se crei una tagella così:
    codice:
    CREATE TABLE `table1` (                                                                                                                                                                         
              `id` int(11) NOT NULL default '0',                                                                                                                                                            
              `str1` char(10) default NULL,                                                                                                                                                                 
              `str2` char(15) default NULL,                                                                                                                                                                 
              `str3` varchar(20) default NULL,                                                                                                                                                                 
              PRIMARY KEY  (`id`)                                                                                                                                                                           
            ) TYPE=MyISAM
    dopo aver creato la tabella vai a vedere come mysql l'ha realmente memorizzata...sorpresa! tutti i campi char sono diventati varchar!
    Ora son troppo stanco per fare delle prove, magari le faro' domani, sto per andare a letto
    Comunque mi fido sulla parola



    VVoVe: Mi hai risolto un bel dubbietto, grazie
    Se comunque una tabella dovesse contenere il campo username, come unica stringa mi converrebbe realizzarlo come char(24) invece che come varchar o altro, vero? (non e' il mio caso, ma mi informo per il futuro )
    C'e' molta differenza di prestazioni tra una tabella senza campi dinamici e una con campi dinamici? E le operazioni che vengono maggiormente rallentate quali sono? Update, Insert, Select o Remove?


    Ultima modifica ad opera dell'utente /dev/null il 01-01-0001 alle 00:00

  9. #9
    CHAR e VARCHAR....

    Mysql gestisce solo un tipo di campo per le stringhe, o dinamico oppure fisso. Se hai un VARCHAR nella tabella, tutti i campi CHAR che superano i due o tre digit, non ricordo bene, vengono trasformati in VARCHAR, cosi' come i VARCHAR minori di due o tre digit (c.s.) vengono trasformati in CHAR. I campi CHAR vengono riempiti di spazi per tutta la parte della stringa mancante al totale impostato. Questi spazi vengono poi rimossi alla visualizzazione.

    Il campo a lunghezza variabile, non e' indicato come chiave primaria, meglio un campo fisso e numerico. Per questo e' consigliato l'uso di un campo INT auto increment. E' pur possibile usare campi char o varchar, ma non dovrebbero mai essere modificati oppure NULL e peggiora comunque la performance della chiave primaria.

    Non e' praticamente valutabile la differenza di performance su un campo CHAR o VARCHAR di 20 / 30 digit sia come indice che come analisi del contenuto.

    Piuttosto direi che un campo username, dovrebbe essere UNIQUE e BINARY in modo da essere univoco e case sensitive.


    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  10. #10
    Utente di HTML.it L'avatar di /dev/null
    Registrato dal
    May 2004
    Messaggi
    1,936
    OK
    Parte di cio' che hai detto l'avevo gia' capito dalle risposte di Gianni_T

    Uhm... Un ultima domanda: perche' i campi che supportano il NULL sono piu' lenti?

    Ultima modifica ad opera dell'utente /dev/null il 01-01-0001 alle 00:00

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.