dovrebbe campi quasi univoci avere indici

Question

Ho un campo in un database quasi unico: il 98% delle volte i valori saranno univoci, ma potrebbe avere alcuni duplicati. Non farò molte ricerche in questo campo; dico due volte al mese. La tabella ha attualmente ~ 5000 record e ne guadagnerà circa 150 al mese.

Questo campo dovrebbe avere un indice?

Sto usando MySQL.

Answer 1

Penso che il "quasi unico" sia probabilmente un'aringa rossa. I dati sono unici o non lo sono, ma ciò non determina se si desidera indicizzarli per motivi di prestazioni.

Risposta:

5000 record in realtà non sono molti e, indipendentemente dal fatto che tu abbia un indice, le ricerche saranno comunque veloci. A quel ritmo di inserti, ci vorranno 3 anni per arrivare a 10000 record, che non sono ancora molti.
Personalmente non mi preoccuperei di aggiungere un indice, ma non importa se lo facessi.

Spiegazione:

Quello che devi pensare quando decidi di aggiungere un indice è il compromesso tra la velocità di inserimento e la velocità di selezione.

Senza un indice, facendo un select su quel campo significa che MySQL deve camminare su ogni singola riga e leggere ogni singolo campo. L'aggiunta di un indice impedisce questo.

Il rovescio della medaglia dell'indice è che ogni volta che i dati vengono inseriti, il DB deve aggiornare l'indice oltre ad aggiungere i dati. Questo di solito è un piccolo sovraccarico, ma lo noteresti davvero se avessi un sacco di indici e stavi scrivendo un sacco.

Quando ottieni così tante righe nel tuo database, vorresti comunque un indice, altrimenti le selezioni richiederebbero tutto il giorno, ma è solo qualcosa di cui devi essere consapevole in modo da non finire per aggiungere indici su campi " nel caso ne avessi bisogno "

Answer 2

Non sono affatto molti record; Non mi preoccuperei di fare alcun indice su quel tavolo. La relativa unicità del campo è irrilevante - anche su hardware di prodotti vecchio di anni mi aspetterei che una query su quella tabella impieghi una frazione di secondo.

Answer 3

puoi usare la regola generale: ottimizza quando diventa un problema. Basta non usare un indice finché non ti accorgi di averne bisogno.

Answer 4

Da quello che dici, non sembra necessario un indice. La regola empirica sono i campi indice che vengono utilizzati molto in SELECTS per accelerare la ricerca, che a sua volta (può) rallenta INSERTI e AGGIORNAMENTI.

Su un recordset piccolo come il tuo, non credo che vedrai colpire gran parte del mondo reale in entrambi i casi.

Answer 5

Se farai ricerche su di esso due volte al mese ed è così poche righe, direi di non indicizzarlo. È quasi inutile.

Answer 6

No. Non ci sono molti record e non sarà richiesto frequentemente. Non è necessario indicizzare.

Answer 7

È davvero un giudizio. Con una tabella così piccola puoi cercare ragionevolmente rapidamente senza un indice, così puoi cavartela senza di essa.

D'altra parte, il costo di creazione di un indice di cui non hai davvero bisogno è piuttosto basso, quindi non ti risparmierai molto non facendolo.

Inoltre, se crei l'indice, sei coperto per il futuro se inizi improvvisamente a ottenere 1000 nuovi record / settimana. Forse conosci abbastanza bene la situazione per dire con certezza che ciò non accadrà mai, ma i requisiti hanno un modo di cambiare quando meno te lo aspetti.

EDIT: per quanto riguarda la modifica dei requisiti, la cosa da considerare è questa: se il DB cresce e scopri in seguito che hai bisogno di un indice, puoi semplicemente creare l'indice ed essere fatto? O dovrai anche cambiare un sacco di codice per utilizzare il nuovo indice?

Answer 8

Dipende. Come altri hanno risposto, c'è un compromesso tra la velocità di aggiornamento della tabella e la velocità di selezione. L'aggiornamento della tabella include inserimenti, aggiornamenti ed eliminazioni nella tabella.

Una domanda a cui non hai risposto. La tabella ha una chiave primaria e un indice corrispondente? Una tabella senza indici solitamente beneficia di almeno un indice. Il modo più comune per ottenere quell'indice è dichiarare una chiave primaria e fare affidamento sul DBMS per generare un indice di conseguenza.

Se una tabella non ha candidati per la chiave primaria, ciò indica di solito un grave difetto nella progettazione della tabella. Questo è un problema separato e dovrebbe avere una discussione spearate.