Sinceramente non vedo grandi differenze, sono tutte comparazioni const e usi sempre un indice. Hai problemi di prestazioni?
Lo slug è una sorta di id testuale del post? Hai pensato di registrare l'md5 dello slug in un campo indicizzato? La chiave sarebbe lunga 32 invece di 767...
Sto studiando una struttura del db che possa reggere alto traffico (più in lettura che in scrittura), quindi per ora non ho problemi, ma voglio evitarli quando il progetto sara in produzione (milioni di record con migliaia di interrogazioni).Originariamente inviata da razzoli
Comunque di differenze ce ne sono, anche se, credo, minime, almeno dal report che ho postato.
Per esempio nell'Extra del primo report leggo 2 using index, mentre nel secondo report c'è un solo using where (che credo sia peggiore dell'altro).
A questo non avevo pensato (key_len), grazie.
Ciao!!!
Originariamente inviato da kalamaro
una volta avevate linkato la pagina di un software per eliminare i ciao! di debug dai post, ho provato nel mio negozio di fiducia a scaffale non lo hanno, vi ricordate il nome?
Entrambe le query usano un indice. La differenza è che "Using index" significa che usa solo l'indice, senza dover accedere ai dati. Si parla di Covering Index. Però... stiamo parlando di una sola riga, quindi anche se deve accedere ai dati non cambia nulla
Visto che ci sono così poche differenze (più che altro, non credo incidano sulle prestazioni) io userei l'indice su una colonna.
E se parlassimo di estrarre X campi? Diciamo per esempio un centinaio.Entrambe le query usano un indice. La differenza è che "Using index" significa che usa solo l'indice, senza dover accedere ai dati. Si parla di Covering Index. Però... stiamo parlando di una sola riga, quindi anche se deve accedere ai dati non cambia nulla
Come mai questa scelta?
Ciao!
Originariamente inviato da kalamaro
una volta avevate linkato la pagina di un software per eliminare i ciao! di debug dai post, ho provato nel mio negozio di fiducia a scaffale non lo hanno, vi ricordate il nome?
Non ho capito la domanda. MySQL usa i covering index solo se tutti i campi che deve leggere sono indicizzati, altrimenti dovrà leggere anche i dati. Se fai SELECT id WHERE nome='x' e nome è indicizzato, l'indice è "covering" per questa query. Se selezioni anche un campo che non è indicizzato, l'indice non è covering.
Mi stai chiedendo se conviene fare un indice di 100 campi? No, occuperebbe tanta memoria e le operazioni di lettura dell'indice sarebbero più lente.
I covering index fanno la differenza se devi leggere molte righe.
In generale l'indice deve essere as small as possible. E' giusto aggiungere una colonna solo se ci sono dei vantaggi. Ma in questo caso, tutti e due i query plan sono praticamente perfetti. (a parte la lunghezza dell'indice slug)
Ciao
No intendevo se dovessi estrarre un numero X di righe in base ad una select del tipo Where author_id = 'xy' (che corrisponde a tutti i post di quell'autore), oppure tutti i post in un range temporale.
Ciao!!
Originariamente inviato da kalamaro
una volta avevate linkato la pagina di un software per eliminare i ciao! di debug dai post, ho provato nel mio negozio di fiducia a scaffale non lo hanno, vi ricordate il nome?
Sì in quel caso un covering index è più efficiente... ma se la query è efficiente lo stesso, non aggiungere campi.
Permessi di invio
Rispondi quotando