Devo aggiungere un nuovo indice a colonna singola a una tabella se esiste già un indice a più colonne su quel campo?

Ho una tabella con un UNIQUEindice multi-colonna su _job_id__e __keyword_id__.

Dovrei anche aggiungere un altro indice a __job_id__se ho una domanda frequente che esegue un GROUP BYsu quella colonna?

(a 100 milioni di righe potrebbe volerci un po '. Ecco perché lo sto chiedendo invece di limitarmi a fare)

No, per niente !!! MySQL Query Optimizer farà la cosa giusta se la colonna o le colonne principali necessarie sono all'estrema sinistra dell'indice. Se hai creato un tale indice, lo Strumento per ottimizzare le query MySQL potrebbe non utilizzare mai tale indice se esegui sempre GROUP BY job_id, keyword_id. MySQL Query Optimizer può o meno utilizzare l'indice se raccogli record solo da job_id, ma hai comunque un indice ridondante che spreca spazio.

Se la tabella è MyISAM, creare un indice del genere farebbe gonfiare il file MYI.

Se la tabella è InnoDB e innodb_file_per_table è 0, la creazione di un tale indice non farebbe che gonfiare ibdata1.

Se la tabella è InnoDB e innodb_file_per_table è 1, la creazione di un tale indice significherebbe solo gonfiare il file .ibd della tabella.

In sintesi, non è necessario creare quell'indice aggiuntivo !!!

Gli indici possono accelerare le group byoperazioni solo riducendo l'ordinamento : ciò sarà più efficiente se l'indice utilizzato è l' indice cluster o almeno ha la stessa colonna iniziale dell'indice cluster. In tutto ciò, suppongo che MySQL non abbia un equivalente di hash group byun'operazione che normalmente escluderebbe qualsiasi vantaggio dagli indici - forse qualcun altro può confermarlo.

Vi è un vantaggio marginale nell'avere un indice separato nel job_idpresupporre che sia l'unica colonna nella group byclausola e nessuno dei due è l'indice cluster: l'indice sarà più piccolo e quindi la scansione genererà meno I / O

--MODIFICARE--

Poiché un indice contiene tutti i campi chiave primaria definiti per la chiave di indice cluster che non si trovano nell'indice secondario , un indice attivo job_idsarà più piccolo di un indice solo job_id, keyword_idse keyword_idnon fa parte dell'indice cluster.