Quanto è sbagliato avere un indice unico e normale sulla stessa colonna?

Question

Ho la seguente struttura di tabella

CREATE TABLE `table` (
  `id` int(11) NOT NULL auto_increment,
  `date_expired` datetime NOT NULL,
  `user_id` int(11) NOT NULL,
  `foreign_id` int(11) NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `date_expired` (`date_expired`,`user_id`,`foreign_id`),
  KEY `user_id` (`user_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Come noterai, ho indici duplicati su user_id: date_expired & amp; user_id . Ovviamente desidero l'indice univoco perché voglio garantire che i dati siano univoci.

Il motivo degli indici duplicati è perché senza l'indice user_id , la mia query di ricerca principale richiede 4 secondi. Con l'indice aggiuntivo ci vogliono 1 secondo. La query si unisce alla tabella su user_id e sta verificando date_expired .

La tabella ha solo 275 record.

• Quanto è male avere un indice unico e normale sullo stesso campo?
• Quanto è male avere indici più grandi dei dati quando la tabella è puramente id?

Answer 1

Credo che se hai creato il tuo indice univoco come ( user_id , date_expired , foreign_id ), otterrai lo stesso vantaggio di avere un indice normale su user_id con solo l'indice univoco. MySQL può utilizzare le prime colonne di qualsiasi indice per ridurre il numero di righe nel join allo stesso modo di un indice su user_id .

Vedi Documentazione sull'indice di MySQL per ulteriori informazioni informazioni.

Ti stai riferendo alla colonna id auto_increment altrove nello schema per risparmiare spazio? Poiché il tuo indice univoco copre tutte le altre colonne della tabella, in sostanza è una chiave primaria stessa e potrebbe essere eliminata in caso contrario.

Puoi controllare quali chiavi sta usando la tua query aggiungendo il prefisso con EXPLAIN.

Answer 2

Non capisco cosa intendi per indici duplicati. Hai tre indici nella tabella:

1. Uno per la chiave primaria "id" (che implica univoco)
2. Un altro unico per la combinazione di 'date_expired', 'user_id' e 'foreign_id'
3. E un terzo solo su 'user_id'

quindi non c'è duplicazione, hai tre diversi indici che faranno cose diverse. È necessario il numero 3 per velocizzare le query relative a user_id, che è quello che stai vedendo. Quindi non c'è niente di sbagliato in questa particolare tabella, non stai duplicando nulla. Per quanto riguarda la seconda domanda, dipende dalle tue esigenze, ma certamente non è cattivo avere più spazio utilizzato negli indici rispetto ai dati.

Ciò che sarebbe male, ad esempio, è avere un UNIQUE ('user_id') e successivamente un KEY ('user_id') (non sono nemmeno sicuro che MySQL lo consenta) perché un indice conterrebbe l'altro e non c'è nulla da guadagnare.

Answer 3

Avere diversi indici tra cui un campo non è affatto male (essenzialmente, indicizzano cose diverse). Ha un leggero impatto sulla performance di scrittura, ma questo è il tipico compromesso che hai con ogni indice al primo posto. Avere indici che occupano più spazio dei dati stessi non è male se lo spazio è economico. Nel tuo caso, dovrebbe essere economico dato il fatto che hai un numero davvero esiguo di voci.

La domanda che vorrei porre nella tua posizione è: in che modo l'indicizzazione di una tabella così piccola influisce in modo così grave sul mio tempo di esecuzione della query? Forse stai facendo qualcosa di sbagliato (penso a molte query eventualmente ridondanti a questa tabella), in quanto una sola dovrebbe essere in nessun posto vicino a questo intervallo di tempo con questo piccolo numero di voci).