Barguast's questions

Depois de executar uma consulta bastante pesada, o plano de execução me deu uma sugestão de índice ausente que era da forma:

(Timestamp) INCLUDE (CustomerID, EventID, ID, EmployeeID)

O que parece ser um índice de cobertura (a coluna INCLUDE são todas chaves primárias (ID) ou chaves estrangeiras). No entanto, minha cláusula WHERE de consultas está filtrando por timestamp, CustomerID e EventID. Não sei por que eles não foram incluídos na parte principal do índice.

Portanto, minha pergunta é: há alguma diferença em usar o índice sugerido acima ou qual é a melhor alternativa;

(Timestamp, CustomerID, EventID) INCLUDE (ID, EmployeeID)

Meu entendimento é que isso ainda permitirá a busca de índice somente de carimbo de data/hora, mas também ajudará ainda mais minha consulta por ter os IDs do cliente e do evento (que são filtrados) na parte principal.

Acho que isso tem algo a ver com a largura da parte 'principal' - FYI, timestamp é um datetime2 (0), CustomerID é um int e EventID é um byte.

Estou testando isso sozinho no momento, mas esta é uma tabela ENORME - mais de 1.000.000.000 de linhas - e está demorando para comparar os índices. Isso, e eu gostaria de aprender mais sobre isso.

Obrigado.

Sei que esse tipo de pergunta surge muito, mas ainda não li nenhum argumento convincente para me ajudar a tomar essa decisão. Por favor, tenha paciência comigo!

Eu tenho um banco de dados enorme - ele cresce cerca de 10.000.000 de registros por dia. Os dados são relacionais e, por motivos de desempenho, carrego a tabela com BULK COPY. Por esse motivo, preciso gerar chaves para as linhas e não posso contar com uma coluna IDENTITY.

Um inteiro de 64 bits - um bigint - é grande o suficiente para eu usar, mas para garantir a exclusividade, preciso de um gerador centralizado para criar meus IDs para mim. Atualmente, tenho um serviço de gerador que permite que um serviço reserve X números de sequência e garanta a ausência de colisões. No entanto, uma consequência disso é que todos os serviços que tenho dependem desse gerador centralizado e, portanto, estou limitado em como posso distribuir meu sistema e não estou satisfeito com as outras dependências (como exigir acesso à rede) impostas por este projeto. Isso tem sido um problema na ocasião.

Agora estou pensando em usar GUIDs sequenciais como minhas chaves primárias (geradas externamente para SQL). Pelo que pude verificar em meus próprios testes, a única desvantagem disso é a sobrecarga de espaço em disco de um tipo de dados mais amplo (que é exacerbado por seu uso em índices). Não testemunhei nenhuma desaceleração perceptível no desempenho da consulta, em comparação com a alternativa bigint. Carregar a tabela com BULK COPY é um pouco mais lento, mas não muito. Meus índices baseados em GUID não estão se tornando fragmentados graças à minha implementação de GUID sequencial.

Basicamente, o que eu quero saber é se há alguma outra consideração que eu possa ter esquecido. No momento, estou inclinado a dar o salto e começar a usar GUIDs. Eu não sou um especialista em banco de dados, então eu realmente aprecio qualquer orientação.