>Se vocé suspeita que um índice é mau para a optimização, pode deshabilitá-o de diversas maneiras. Por >exemplo, pode criar um índice com um filtro. O filtro pode incluir todos os registros.

Nunca fui fão dos filtros pois sempre achei que agiliza a consulta (talvez, pois tem pouca documentação) mas compromete a entrada de dados. Mas isso na minha aplicação que tem uma grande massa de dados entrando a todo momento.

>Também pode deshabilitar um índice para uma consulta específica. Por ejemplo, a consulta:
>
>select * from Movimento;
> where Cliente = "abc" and MovementDate >= {^1990-01-01}
>... usará um índice por MovementDate. Isto pode selecionar muitos registros para o índice >MovementDate.

Sim, mas mesmo assim dependendo da sua massa de dados ainda será muito mais rápido do que um scan, visto que ele será um scan, mas a partir de um momento no tempo em diante o que agiliza muito o processo. Acredito que no máximo ele consegue ser tão lento quanto o scan e não mais do que ele. Se a árvore binaria não for boa, realmente não vale usar índice para ela.

>Se vocé cambiar a consulta a:
>select * from Movimento;
> where Cliente = "abc" and MovementDate + 1 >= {^1990-01-01} + 1
>está deshabilitando o índice por MovementDate, ja que nao concorda exatamente com a condição.

Ai tem um problema, você esta mudando o valor do MovementDate, o melhor seria +0 ou simplesmente inverte a condição, visto que o rushmore pega da esquerda para a direita:

{^1990-01-01} <= MovementDate