Preciso adicionar um novo índice de coluna única a uma tabela se já existir um índice de várias colunas nesse campo?

Não, de jeito nenhum!!! O MySQL Query Optimizer fará a coisa certa se as colunas principais necessárias estiverem mais à esquerda no índice. Se você criou tal índice, o MySQL Query Optimizer pode optar por nunca usar esse índice se você sempre executar GROUP BY job_id,keyword_id. O MySQL Query Optimizer pode ou não usar o índice se você coletar registros apenas por job_id, mas terá um índice redundante desperdiçando espaço de qualquer maneira.

Se a tabela for MyISAM, fazer tal índice apenas aumentaria o tamanho do arquivo MYI.

Se a tabela for InnoDB e innodb_file_per_table for 0, criar esse índice apenas aumentaria o ibdata1.

Se a tabela for InnoDB e innodb_file_per_table for 1, criar esse índice apenas aumentaria o tamanho do arquivo .ibd da tabela.

Resumindo, não precisa fazer aquele índice adicional!!!

Os índices só podem acelerar as group byoperações reduzindo a classificação - isso será mais eficiente se o índice usado for o índice clusterizado ou pelo menos tiver a mesma coluna inicial que o índice clusterizado. Em tudo isso, estou assumindo que o MySQL não tem equivalente a uma hash group byoperação que normalmente ignoraria qualquer benefício dos índices - talvez alguém possa confirmar isso.

Há um benefício marginal em ter um índice separado ao job_idassumir que é a única coluna na group bycláusula e nenhum é o índice clusterizado: o índice será menor e, portanto, a varredura gerará menos E/S

--EDITAR--

Como um índice contém todos os campos de chave primária definidos para a chave de índice clusterizado que não estão no índice secundário , um índice job_idsomente será menor que um índice job_id, keyword_idse keyword_idnão fizer parte do índice clusterizado.