Quando você deseja a velocidade máxima de recuperação e tem ambas as colunas nas condições de junção ou onde, MAS às vezes a coluna a tem maior seletividade e às vezes a coluna b tem maior seletividade e você deseja capitalizar esse fato a partir de um único índice.

Também acho que sua proporção de tamanho de dados / desempenho da máquina deve ser bastante alta e, ao mesmo tempo, você terá que (supor) estar disposto a chamar qualquer melhoria de necessidade (mesmo que apenas por algumas porcentagens).

Ainda assim, a experiência ensina que as coisas dependem de muitos fatores; com ambientes de aplicativos e RDBMS específicos, é melhor executar seus próprios benchmarks.

EDIT:Mais explicações sobre índices compostos. da wikipedia :
"A ordem em que as colunas são listadas na definição do índice é importante. É possível recuperar um conjunto de identificadores de linha usando apenas a primeira coluna indexada. No entanto, não é possível ou eficiente (no maioria dos bancos de dados) para recuperar o conjunto de identificadores de linha usando apenas a segunda ou maior coluna indexada.
Por exemplo, imagine uma lista telefônica organizada primeiro por cidade, depois por sobrenome e depois por nome. recebem a cidade, você pode facilmente extrair a lista de todos os números de telefone dessa cidade. No entanto, nesta lista telefônica, seria muito tedioso encontrar todos os números de telefone para um determinado sobrenome. Você teria que procurar dentro do nome de cada cidade seção para as entradas com esse sobrenome."

As explicações da Wikipedia talvez sejam simplificadas demais, mas dão a você a ideia básica (como analogias, lembre-se de que as listas telefônicas geralmente têm índices agrupados e esse não seria o índice geral do banco de dados).

Dependendo do tamanho do índice versus tamanho da estrutura de dados versus memória disponível versus seletividade na primeira coluna do índice, ainda pode ser muito menos caro usar o índice ordenado incorretamente do que usar varreduras de tabela.

Ah, acabei de pensar em uma analogia melhor com um exemplo que você está procurando Imagine um bom livro didático, ele teria um índice com capítulos e subcapítulos e número de páginas em que eles estão (que é um índice não agrupado que contém ponteiros para registros de dados - páginas). Agora imagine que o livro está no padrão SQL-92, então a maioria dos termos no TOC seriam termos SQL (mantenha essa suposição). Você também teria outro índice no final do livro que liste todos os termos interessantes em ordem alfabética (vamos supor com os principais nomes dos capítulos) e os números das páginas.

Para perguntas como "Diga-me todos os capítulos em que DISTINCT aparece", você usaria o segundo índice. (porque a seletividade do campo posterior é alta)

Para perguntas como "Diga-me o número dos termos que aparecem no primeiro capítulo", você usaria o sumário

Então, para perguntas como 'O SELECT está descrito no capítulo DML?' você pode usar qualquer um dos índices. (porque a seletividade de ambos os campos é alta) No entanto, se o TOC do próprio DML tiver 3 páginas e a entrada SELECT no índice tiver apenas quinze linhas, você provavelmente irá para o segundo, e isso é um exemplo de quando você se beneficia de ambos os índices.

Agora, se você acha que isso é exagero, leve em consideração um banco de dados da biblioteca digitalizada do congresso. :)

Como eu disse antes, todo o planejamento está bom, mas no final execute seus próprios benchmarks.