lentezza delle query di insert e update

[sean_von_drake]

ciao a tutti,
non so quanto sia comune come problema, ma ho notato dopo aver abilitato il log delle query lente che ci sono nel mio db delle query che impiegano anche svariati secondi! le select invece sono velocissime, anche su tabelle grandi. Può essere un problema di indici, o di configurazione del server?

ho da poco fatto l'aggiornamento a debian squeeze e uso mysql 5.1

qualcuno ha avuto esperienza di problemi simili?

grazie a tutti!

[piero.mac]

per insert, update, delete gli indici sono una palla al piede perche' dopo ogni variazione questi indici devono essere ricostruiti.

[sean_von_drake]

si ho notato

ma è possibile che la cosa sia peggiorata dopo l'aggiornamento di versione?

[piero.mac]

Originariamente inviato da sean_von_drake
si ho notato

ma è possibile che la cosa sia peggiorata dopo l'aggiornamento di versione?

Questo non te lo saprei dire. Sicuramente se gli indici sono svariati nel numero e tipo piu' le tabelle si gonfiano e sempre peggio e'. A volte per grosse variazioni conviene togliere gli indici e ricrearli alla fine del lavoro. Dipende anche da cosa si intende per "tanto tempo" svariati secondi una tantum non sono poi molti. Svariati secondi tante volte al giorno possono essere molti. In questo caso pero' direi di valutare la convenienza di tenere piu' indici magari poco utili.

[deleted_29]

Originariamente inviato da sean_von_drake
ciao a tutti,
non so quanto sia comune come problema, ma ho notato dopo aver abilitato il log delle query lente che ci sono nel mio db delle query che impiegano anche svariati secondi! le select invece sono velocissime, anche su tabelle grandi. Può essere un problema di indici, o di configurazione del server?

ho da poco fatto l'aggiornamento a debian squeeze e uso mysql 5.1

qualcuno ha avuto esperienza di problemi simili?

grazie a tutti!

mancano delle informazioni

Innanzitutto se usi innodb o myisam, e quale sia il mix di letture e scritture sugli archivi. Le scritture, per loro natura, non sono parallelizzabili, il che può determinare (in generale determina, se non nel caso dell'accodamento) rallentamenti dovuti alla necessità non tanto (o meglio non solo) di aggiornare gli indici, quanto di doversi "accodare".

La primissima cosa da fare è trasformare le update ed insert in select, e guardare con explain select quale sia la situazione

[sean_von_drake]

si purtroppo innodb ti obbliga a tenere degli indici per far funzionare le relazioni fra tabelle... può avere senso schedulare la ricostruzione degli indici ogni tot su certe tabelle?

[deleted_29]

Originariamente inviato da sean_von_drake
si purtroppo innodb ti obbliga a tenere degli indici per far funzionare le relazioni fra tabelle... può avere senso schedulare la ricostruzione degli indici ogni tot su certe tabelle?

in generale... no

ha senso fare una progettazione "furba".

e, per inciso, innodb ha uno ed uno solo indice "necessario", che è quello della chiave primaria, che viene aggiunta "occulta" se non specificata.

Attenzione che la modalità di aggregazione delle chiave primaria innodb è rilevante, in quanto determina l'ordine dei record nelle pagine e può rallentare l'accesso, soprattutto quando si usano (ovviamente) dischi magnetici e non SSD (o la cache)

[sean_von_drake]

Originariamente inviato da franzauker
in generale... no

ha senso fare una progettazione "furba".

e, per inciso, innodb ha uno ed uno solo indice "necessario", che è quello della chiave primaria, che viene aggiunta "occulta" se non specificata.

Attenzione che la modalità di aggregazione delle chiave primaria innodb è rilevante, in quanto determina l'ordine dei record nelle pagine e può rallentare l'accesso, soprattutto quando si usano (ovviamente) dischi magnetici e non SSD (o la cache)

quello che intendevo dire è che per avere i vincoli fra tabelle le colonne relative al vincolo devono essere degli indici che io sappia... o no?

ovvio che "pompare" l'hardware è sempre una soluzione percorribile

[deleted_29]

Originariamente inviato da sean_von_drake
quello che intendevo dire è che per avere i vincoli fra tabelle le colonne relative al vincolo devono essere degli indici che io sappia... o no?

per "vincoli" intendi chiavi importate?
la risposta è sì
se per "vincoli" intendi semplici relazioni, allora no.
Personalmente saranno un 15 anni che non uso "vincoli" (intesi come specifici dell'RDBMS), ma ognuno si regola secondo le proprie preferenze.

ovvio che "pompare" l'hardware è sempre una soluzione percorribile

non è detto, anzi in generale ciò non avviene con mysql.
Non è tanto avere un hw più veloce, quanto un hw DIVERSO nel funzionamento (con riferimento al meccanismo di chiave primaria innodb che ordina i record).

Questo fa sì che la latenza di una chiave primaria non ordinata (nel caso di un accesso invece ordinato) è elevata nel caso di dischi magnetici, ininfluente nel caso di memorie ad accesso diretto.

[sean_von_drake]

Originariamente inviato da franzauker
per "vincoli" intendi chiavi importate?
la risposta è sì
se per "vincoli" intendi semplici relazioni, allora no.
Personalmente saranno un 15 anni che non uso "vincoli" (intesi come specifici dell'RDBMS), ma ognuno si regola secondo le proprie preferenze.

per vincoli intendo le relazioni fra tabelle tali per cui puoi impedire o propagare a cascata secondo necessità le operazioni di cancellazione o modifica