Dois-je ajouter un nouvel index à colonne unique à une table si un index à plusieurs colonnes sur ce champ existe déjà?

J'ai une table avec un UNIQUEindex multi-colonnes sur _job_id__et __keyword_id__.

Aurais-je également besoin d'ajouter un autre index __job_id__si j'ai une requête fréquente qui effectue un GROUP BYsur cette colonne?

(À 100 millions de lignes, cela pourrait prendre un certain temps. C'est pourquoi je demande au lieu de simplement le faire)

Non pas du tout !!! L'optimiseur de requêtes MySQL fera la bonne chose si la ou les colonnes principales nécessaires sont les plus à gauche dans l'index. Si vous avez créé un tel index, MySQL Query Optimizer peut choisir de ne jamais utiliser cet index si vous exécutez toujours GROUP BY job_id, keyword_id. MySQL Query Optimizer peut ou non utiliser l'index si vous collectez des enregistrements par job_id uniquement, mais vous avez quand même un espace d'indexage redondant.

Si la table est MyISAM, la création d'un tel index ne ferait que gonfler le fichier MYI.

Si la table est InnoDB et innodb_file_per_table est 0, faire un tel index ne ferait que gonfler ibdata1.

Si la table est InnoDB et innodb_file_per_table est 1, la création d'un tel index ne ferait que gonfler le fichier .ibd de la table.

En résumé, vous n'avez pas besoin de faire cet index supplémentaire !!!

Les index ne peuvent accélérer les group byopérations qu'en réduisant le tri - cela sera plus efficace si l'index utilisé est l' index clusterisé ou a au moins la même colonne de tête que l'index clusterisé. Dans tout cela, je suppose que MySQL n'a pas d'équivalent d'une hash group byopération qui contournerait généralement tous les avantages des index - peut-être que quelqu'un d'autre peut le confirmer.

Il y a un avantage marginal à avoir un index séparé en job_idsupposant qu'il s'agit de la seule colonne de la group byclause et que l'index cluster n'est pas non plus: l'index sera plus petit et donc le scanner générera moins d'E / S

--ÉDITER--

Comme un index contient tous les champs de clé primaire définis pour la clé d'index cluster qui ne sont pas dans l'index secondaire , un index sur job_idne sera plus petit qu'un index sur job_id, keyword_ids'il keyword_idne fait pas partie de l'index cluster.