Andrew Barber's questions

Estou construindo um índice composto e não tenho 100% de certeza de como incluir um bitcampo que faz parte da tabela. O índice será para algo semelhante a uma lista de tópicos do fórum, onde eu quero que o índice único seja por ForumId(int), IsSticky(bit), então DatePosted (desc)(datetime2(0))

Mas quero ter certeza de que manipulo o IsStickycampo de bits corretamente; Devo indexá-lo como se truefosse 1ou -1? Se for 1, eu indexaria IsSticky descendente; se -1, eu o indexaria ascendente.

Além disso, estou pedindo SQL 2008, mas gostaria de saber se é diferente em 2005.

De certa forma, já sei a resposta para essa pergunta, mas sempre sinto que preciso aprender mais sobre o assunto.

Meu entendimento básico é que, de um modo geral, um único índice que inclui apenas todos os campos que você pode consultar/classificar em um determinado momento provavelmente não será útil, mas já vi esse tipo de coisa. Alguém pensou: "Bem, se apenas colocarmos tudo isso em um índice, o banco de dados pode usá-lo para encontrar o que precisa", sem nunca ter visto um plano de execução para algumas das consultas reais sendo executadas.

Imagine uma tabela assim:

id int pk/uid
name varchar(50)
customerId int (foreign key)
dateCreated datetime

Posso ver um único índice incluindo os campos name, customerIde .dateCreated

Mas meu entendimento é que tal índice não seria utilizado em uma consulta como, por exemplo:

SELECT [id], [name], [customerId], [dateCreated]
   FROM Representatives WHERE customerId=1 
   ORDER BY dateCreated

Para tal consulta, parece-me que uma ideia melhor seria um índice incluindo os campos customerIde , com o campo sendo 'primeiro'. Isso criaria um índice que teria os dados organizados de forma que essa consulta pudesse encontrar rapidamente o que precisa - na ordem em que precisa.dateCreatedcustomerId

Outra coisa que vejo, talvez com tanta frequência quanto a primeira, são os índices individuais em cada campo; então, um em cada namee customerIdcampos dateCreated.

Ao contrário do primeiro exemplo, esse tipo de arranjo me parece às vezes pelo menos parcialmente útil; o plano de execução da consulta pode mostrar que pelo menos está usando o índice no customerIdpara selecionar os registros, mas não está usando o índice com o dateCreatedcampo para ordená-los.

Eu sei que esta é uma pergunta ampla, porque a resposta específica para qualquer consulta específica em qualquer conjunto específico de tabelas geralmente é ver o que o plano de execução diz que fará e, caso contrário, levar em consideração as especificidades da(s) tabela(s) e consultas conta. Além disso, sei que depende da frequência com que uma consulta pode ser executada, em oposição à sobrecarga de manter um índice específico para ela.

Mas suponho que o que estou perguntando é como um 'ponto de partida' geral para índices, a ideia de ter índices específicos para consultas específicas e frequentes e os campos nas cláusulas WHERE ou ORDER BY faz sentido?