[SQL] Problema di Performance su Query

[skidx]

Originariamente inviato da webus
Comunque dei miglioramenti li si potrebbero ottenere anche accorciando l'indice. Raramente infatti è necessario indicizzare oltre i primi 10-12 caratteri, e nel caso si tratti ad esempio di un char(255) la differenza si farebbe notevole. Ovviamente dovrebbe fare dei test per valutare la lunghezza necessaria.

in quel caso dovrebbe anche cambiare il tipo di indice in quanto non sarebbe più "UNIQUE", perché i primi N caratteri di stringhe diverse potrebbero verosimilmente coincidere.

[skidx]

Originariamente inviato da daniele_dll
scusami, ma se accorci il valore da 255 a, per esempio, 12 ottieni comunque un lavoro maggiore rispetto all'uso di un hash numerico settato sempre come chiave indice

Il campo in questione è già indicizzato da MySQL quindi non ha senso fare un ulteriore indice "a mano" soprattutto in virtù del fatto che il tuo sistema non lascia la libertà all'utente di scegliersi il nome utente che preferisce (a causa delle collisioni).

Comunque stiamo parlando di un falso problema, perché il motivo per cui non vuole usare l'ID al posto dello username è infondato.

[webus]

Originariamente inviato da daniele_dll
scusami, ma se accorci il valore da 255 a, per esempio, 12 ottieni comunque un lavoro maggiore rispetto all'uso di un hash numerico settato sempre come chiave indice

sì, ma le differenze sono comunque irrisorie, e non tali da far parlare di problemi di performance.
Lascia d esempio più perplesso lo star come selettore delle colonne, che è in genere segnale di poca accortezza nello scrivere le query.

Conta di più la posizione gerarchica della colonna nickname, nel caso fosse in coda alla tabella o peggio ancora se prima della colonna ve ne fosse una blob.

Intendo dire, gli aspetti che influiscono possono essere tanti, ma nessuno preso singolarmente giustifica un problema di performance.
Salvo che la query non sia in realtà contro un'unica tabella come quella postata sopra.

[daniele_dll]

Originariamente inviato da skidx
Il campo in questione è già indicizzato da MySQL quindi non ha senso fare un ulteriore indice "a mano" soprattutto in virtù del fatto che il tuo sistema non lascia la libertà all'utente di scegliersi il nome utente che preferisce (a causa delle collisioni).

Comunque stiamo parlando di un falso problema, perché il motivo per cui non vuole usare l'ID al posto dello username è infondato.

si ma la questione è ben diversa ... mysql non tiene mica un hash della stringa nell'indice perché non avrebbe l'assoluta certezza dell'unicità, o no?

mentre un hash crc32 è un numero

ho fatto qualche test e qualche guadagno c'è, ma ovviamente non è eccezionale, come diceva webus

[webus]

Originariamente inviato da skidx
in quel caso dovrebbe anche cambiare il tipo di indice in quanto non sarebbe più "UNIQUE", perché i primi N caratteri di stringhe diverse potrebbero verosimilmente coincidere.

ovviamente dovrebbe prima fare una verifica sulla colonna, ma è abbastanz aprobabile che la possa accorciare, anche di molto.

Originariamente inviato da skidx
Comunque stiamo parlando di un falso problema, perché il motivo per cui non vuole usare l'ID al posto dello username è infondato.

beh, un utente ricorda più facilmente un nick che un numero. E pure a livello psicologico, non sarebbe il massimo vedersi chiedere un codice numerico per farsi riconoscere.

[skidx]

Originariamente inviato da daniele_dll
si ma la questione è ben diversa ... mysql non tiene mica un hash della stringa nell'indice perché non avrebbe l'assoluta certezza dell'unicità, o no?

mentre un hash crc32 è un numero

ho fatto qualche test e qualche guadagno c'è, ma ovviamente non è eccezionale, come diceva webus

gli indici sono B-tree, sia per i numeri che per le stringhe (parlo di InnoDB). In questo tipo di ricerche come è anche intuitivo pesa molto di più il numero di iterazioni per trovare l'elemento più del singolo confronto a ogni iterazione, cosa confermata appunto anche dal tuo test. Il numero di iterazioni in un B-tree è identico che siano numeri o stringhe. Per questo dicevo che non ha senso fare un altro indice "a mano", perché a fronte di un guadagno veramente marginale introdurrebbe limitazioni d'uso molto più importanti.

[skidx]

Originariamente inviato da webus
beh, un utente ricorda più facilmente un nick che un numero. E pure a livello psicologico, non sarebbe il massimo vedersi chiedere un codice numerico per farsi riconoscere.

Ovvio, quello nella procedura di login, ma se leggi il primo post lui parla di passare quel valore in chiaro negli URL creati dinamicamente, non del login, e ha paura che esporre negli URL l'ID crei problemi di sicurezza rispetto a esporre il nickname, preoccupazione del tutto infondata (casomai è vero il contrario, se il nickname serve per il login )

[skidx]

per capirci, lui ha dei link tipo questo:

http://forum.html.it/forum/member.ph...o&userid=16988

e vorrebbe metterci il nick al posto dell'ID per paura di non so che.
Quindi è inutile.

[webus]

Originariamente inviato da skidx
Ovvio, quello nella procedura di login, ma se leggi il primo post lui parla di passare quel valore in chiaro negli URL creati dinamicamente, non del login, e ha paura che esporre negli URL l'ID crei problemi di sicurezza rispetto a esporre il nickname, preoccupazione del tutto infondata (casomai è vero il contrario, se il nickname serve per il login )

ah ok, mi era sfuggito.

[ApocalypseNow]

Grazie mille per le tante risposte. Chiarisco alcuni concetti della mia implementazione.
Il database ha come unici campi: il campo ID , dei campi int, dei campi varchar, e dei campi binary (quindi nessun campo blob). Il nickname è UNIQUE, e non dò la possibilità, nel sito, di cambiarlo. Chi sceglie un nickname, mantiene quello, ed è un campo Varchar(14) che ovviamente non può essere NULL.

Non credevo che il mio "Vorrei usare il nickname per motivi di sicurezza" scatenasse un dibattito Resettiamo la frase, assumendo che l'uso dell'ID non comprometta la sicurezza.

Nel sito ci sono ad esempio le pagine dei profili. Ipotizziamo:

http://www.miaurl.it/profilo.php?n=Tizio

e si apre la pagina del profilo di Tizio. Chiaramente è più elegante e più sicuro usare il nickname. Così un utente esperto può accedere al profilo di un altro utente semplicemente modificando il valore della n nel browser, e in genere modifica con un nome che conosce. Così facendo evito che un utente che non ha niente da fare inserisca degli ID a caso, entrando in profili di sconosciuti, creando scompiglio nei profili (che registrano gli ingressi utente, e sono query sql), ciucciandomi banda ecc.

Ora.....ho 150.000 utenti e crescono rapidamente. Vorrei ottimizzare la query in modo che all'aumentare degli utenti, aumenti relativamente di poco l'esecuzione della query. E' inutile usare LIMIT 1, tanto AL MASSIMO la query restitusce 1 valore. Se non trova l'utente ne restituisce 0...ma non più di 1

Grazie ancora per le risposte e spero che i chiarimenti siano serviti