Onde colocar índices em uma tabela de dimensão de tempo?

Depois de ler as Perguntas e respostas deste site sobre índices, uma pergunta veio à minha mente.

E se, estiver usando uma tabela de dimensão de tempo com o menor nível de granularidade sendo o dia. Onde se deve colocar os índices?

Randy Melder na pergunta: O que significa "índice" no RDBMS? disse :

Pense em um índice como "índice" ... que é uma lista ordenada de ponteiros para posições em um arquivo, também conhecido como deslocamentos

No caso da dimensão de tempo, a maioria das pesquisas de dados pode ser feita para um dia específico, uma semana específica, um mês específico ou um trimestre específico se o horário armazenar todo o dia durante um ano único .

Minha pergunta é: deve-se colocar índices para todos esses campos?

O dia deve ser único, portanto, para este, eu entendo perfeitamente o uso de índices. Mas uma identificação de semana terá 7 ocorrências , uma identificação de mês terá 30/31 ocorrências , uma identificação de trimestre terá mais ou menos 120 ocorrências .

• Ainda se deve colocar índices para esses campos?
• Ainda será útil?

Estou lhe perguntando isso porque, na mesma pergunta, David Spillett disse:

Adicionar índices demais pode ser uma otimização ruim, é claro, pois o espaço extra usado para armazenar os índices (e a carga de IO para mantê-los se o seu banco de dados vê muitas operações de gravação) pode ser um problema pior do que as consultas de leitura um pouco menos ideais , então não exagere.

Então, quais seriam as melhores considerações para o caso da dimensão temporal?

Você provavelmente não vai se deparar com problemas de gravação, pois presumo que isso seria algo criado uma vez (ou uma vez por ano) e depois não tocado.

Mas o uso de um índice provavelmente será um obstáculo se você estiver pesquisando por semana ... O problema é que, se o índice for usado, ele poderá varrer primeiro e depois pegar cada registro da tabela individualmente, e quando você ' Ao extrair mais de 5 a 20% dos registros, normalmente é mais rápido fazer uma varredura completa da tabela e soltar os registros de que você não se importa.

Não conheço nenhum RDBMS principal que não seja otimizado para isso quando se trata de dados bem distribuídos. Se não estiver bem distribuído (por exemplo, um dos valores em uma coluna ocorre 95% das vezes, mas também existem outros valores possíveis), talvez você precise calcular histogramas na tabela e não usar um espaço reservado para o valor ao pesquisar, para que o otimizador de consulta tenha o valor que está sendo pesquisado ao gerar o plano de execução.

Eu provavelmente não indexaria o dia da semana. Eu verificaria a documentação do meu banco de dados para ver qual é a troca entre as leituras indexadas e as varreduras completas da tabela para ver se eu indexaria o dia do mês ou o mês do ano. Eu provavelmente indexaria DOY / dia do ano, se presente (que parece ser o seu índice exclusivo, de qualquer maneira)

Um índice não precisa ser exclusivo para ser útil; portanto, a resposta é que depende . Se suas consultas se beneficiarem da presença do índice, elas poderão ser uma adição útil. Não sei se deve haver diretrizes especiais em relação às colunas de tempo. Trate-os como qualquer outra coluna e indexe-os com base na utilidade das consultas.

A regra geral é que, quanto mais seletivo for o índice (a seletividade é definida como o número de valores exclusivos em uma coluna dividida pelo número de linhas na tabela), maior a probabilidade de o mecanismo usar o índice se uma consulta usa a coluna em uma cláusula where.

Se você estiver pensando em indexar uma coluna, a execução de uma consulta selecionando na coluna indexada antes e depois e analisando os planos de execução informará se o índice está sendo usado e, em caso afirmativo, quanto o índice está ajudando. Idealmente, a consulta que você usa para o teste é aquela que seria usada pelo seu aplicativo.

Até agora, minha regra geral é não colocar nenhum índice nos meus bancos de dados de desenvolvimento enquanto eu estiver trabalhando neles. À medida que o banco de dados de produção aumenta, eu uso o log de banco de dados e EXPLAINpara descobrir o que precisa de indexação e depois crio apenas os índices necessários. Isso funciona bem desde que o uso do banco de dados aumente gradualmente e mantenha a contagem baixa do índice.

Ao analisar dados no banco de dados, geralmente preciso adicionar índices adicionais para acelerar solicitações que não são comuns na produção. Eu sempre faço isso em cópias do banco de dados de produção, para que esses índices nunca sejam adicionados à produção.