Gostaria de saber se existe alguma maneira inteligente de reescrever a seguinte consulta para que os índices nas colunas sejam usados pelo otimizador?

Create Procedure select_Proc1
    @Key1 int=0,
    @Key2 int=0
As
BEGIN
    Select key3
    From Or_Table
    Where (@key1 =0 OR Key1 =@Key1) AND
          (@key2 =0 OR Key2 =@Key2)
END
GO

Mesmo que as colunas nas cláusulas WHERE sejam cobertas por índices, o SQL Server não pode usar esses índices. Isso levanta a questão de saber se algo está "bloqueando" o uso dos índices. A resposta a esta pergunta é sim - os culpados são os parâmetros e a condição "OU". Os parâmetros não são cobertos por índices, o que significa que o SQL Server não pode usar nenhum dos índices para avaliar “@ key1 = 0” (uma condição que também se aplica a @ key2 = 0). Efetivamente, isso significa que o SQL Server não pode usar índices para avaliar a cláusula "@ key1 = 0 OR Key1 = @ key1" (como a cláusula "OR" é a união de linhas cobertas por ambas as condições). O mesmo princípio se aplica à outra cláusula (re. Chave2). Isso leva o SQL Server a concluir que nenhum índice pode ser usado para extrair as linhas, deixando o SQL Server a utilizar a próxima melhor abordagem - uma verificação de índice em cluster

Como você vê, o otimizador SQL não usará índices nas colunas se os predicados forem "OR" na cláusula WHERE. Uma solução para esse problema é separar as consultas com a cláusula IF para todas as combinações possíveis de parâmetros.

Leia este pequeno artigo para obter uma melhor visão do problema:http://www.sql-server-performance.com/articles/per/optimize_or_clause_p1.aspx

Agora, minha pergunta é: o que devemos fazer se as combinações possíveis forem mais do que apenas três ou quatro? Escrever uma consulta separada para cada combinação não parece uma solução racional. Existe alguma outra solução alternativa para esse problema?