As palavras são bastante lógicas e você vai aprendê-las rapidamente. :)
Em termos leigos, SEEK implica procurar locais precisos para registros, que é o que o SQL Server faz quando a coluna que você está pesquisando é indexada e seu filtro (a condição WHERE) é suficientemente preciso.
SCAN significa um intervalo maior de linhas em que o planejador de execução de consulta estima que é mais rápido buscar um intervalo inteiro em vez de buscar individualmente cada valor.
E sim, você pode ter vários índices no mesmo campo e, às vezes, pode ser uma boa ideia. Jogue com os índices e use o planejador de execução de consulta para determinar o que acontece (atalho no SSMS:Ctrl + M). Você pode até executar duas versões da mesma consulta e o planejador de execução mostrará facilmente quantos recursos e tempo são usados por cada uma, facilitando bastante a otimização.
Mas, para expandir um pouco, digamos que você tenha uma tabela de endereços como essa e tenha mais de 1 bilhão de registros:
CREATE TABLE ADDRESS
(ADDRESS_ID INT -- CLUSTERED primary key ADRESS_PK_IDX
, PERSON_ID INT -- FOREIGN KEY, NONCLUSTERED INDEX ADDRESS_PERSON_IDX
, CITY VARCHAR(256)
, MARKED_FOR_CHECKUP BIT
, **+n^10 different other columns...**)
Agora, se você quiser encontrar todas as informações de endereço da pessoa 12345, o índice em PERSON_ID é perfeito. Como a tabela tem muitos outros dados na mesma linha, seria ineficiente e consumiria espaço criar um índice não clusterizado para cobrir todas as outras colunas, bem como PERSON_ID. Nesse caso, o SQL Server executará um índice SEEK no índice em PERSON_ID e, em seguida, usará isso para fazer uma pesquisa de chave no índice clusterizado em ADDRESS_ID e, a partir daí, retornará todos os dados em todas as outras colunas na mesma linha.
No entanto, digamos que você deseja pesquisar todas as pessoas em uma cidade, mas não precisa de outras informações de endereço. Desta vez, a maneira mais eficaz seria criar um índice em CITY e usar a opção INCLUDE para cobrir PERSON_ID também. Dessa forma, uma única busca/varredura de índice retornaria todas as informações necessárias sem a necessidade de recorrer à verificação do índice CLUSTERED para os dados PERSON_ID na mesma linha.
Agora, digamos que ambas as consultas sejam necessárias, mas ainda bastante pesadas por causa dos 1 bilhão de registros. Mas há uma consulta especial que precisa ser realmente muito rápida. Essa consulta quer todas as pessoas em endereços que foram MARKED_FOR_CHECKUP e que devem morar em Nova York (ignore o que quer que seja o check-up, isso não importa). Agora você pode querer criar um terceiro índice filtrado em MARKED_FOR_CHECKUP e CITY, com INCLUDE cobrindo PERSON_ID e com um filtro dizendo CITY ='New York' e MARKED_FOR_CHECKUP =1. Esse índice seria incrivelmente rápido, pois só cobre consultas que satisfaçam essas condições exatas e, portanto, tenham uma fração dos dados para percorrer em comparação com os outros índices.
(Isenção de responsabilidade aqui, tenha em mente que o planejador de execução de consulta não é estúpido, ele pode usar vários índices não clusterizados juntos para produzir os resultados corretos, portanto, os exemplos acima podem não ser os melhores disponíveis, pois é muito difícil imaginar quando você precisaria 3 índices diferentes cobrindo a mesma coluna, mas tenho certeza que você entendeu.)
Os tipos de índice, suas colunas, colunas incluídas, ordens de classificação, filtros etc dependem inteiramente da situação. Você precisará fazer índices de cobertura para atender a vários tipos diferentes de consultas, bem como índices personalizados criados especificamente para consultas singulares e importantes. Cada índice ocupa espaço no disco rígido, portanto, criar índices inúteis é um desperdício e requer manutenção extra sempre que o modelo de dados muda, além de perder tempo em operações de desfragmentação e atualização de estatísticas... qualquer.
Experimente, aprenda e descubra o que funciona melhor para suas necessidades.
