Está criando parte do índice do banco de dados do processo de design, implementação ou otimização?

Para fins de discussão, vamos ser específico no que queremos dizer (e presumir que você está fazendo TDD):

• Design é o processo de especificar a forma total do seu sistema. Você pode (e algumas vezes deve) projetar sem escrever direta ou indiretamente uma única linha de banco de dados ou código de programa. Você define seus Testes de Aceitação como o último estágio do design.
• Implementação é o processo de transformar esse design em um software "funcional". Se você estiver sendo dogmático, não escreverá um único índice de banco de dados; você apenas definiria as tabelas, escreveria o objeto de interface e confiaria em sua plataforma de nível inferior para carregar os dados. Você escreve Testes de Unidade e Testes de Integração durante a implementação, e a implementação é feita quando os Testes de Aceitação passam.
• A Otimização está fazendo o software "funcional" que você fez em Implementação e acelerando onde ele é executado de maneira inaceitavelmente lenta. As três camadas de teste permitem que você faça alterações sem quebrar nada.

Claro, é assim que funciona na teoria. Mas, como uma questão prática, uma vez que o tempo e o dinheiro são limitados, muitas vezes você vai para as etapas fora de ordem. Se você espera precisar de um índice em um campo específico, não há razão para não indexá-lo ao projetá-lo. Se, durante uma série de códigos, você perceber como pode resolver com elegância uma situação de uso alternativo, pode codificar um rascunho primeiro e escrever o segundo teste da unidade. (E quando você perceber que seu design está errado, você terá que voltar e revisar seus testes de qualquer maneira.)

Quanto às suas perguntas particulares:

Is creating all indexes at the start (design) over engineering?

Não, se todos forem índices úteis e não demorarem muito tempo.

Sim, se você acabar definindo índices para tabelas que estão longe do primeiro protótipo bruto. (Se você criar índices em seu design inicial, submeta-os a testes posteriores. Eles podem ser mais problemas do que valem a pena.)

Should I just skip creating indexes before it's needed because performance issues will show up anyway and probably the indexes that's already been created aren't being used?

Não, se estiver claro que você precisará ter algumas colunas indexadas. Se você planeja um recurso que pesquisa com frequência lances em ações acima ou abaixo de um determinado preço, provavelmente desejará um índice sobre o valor do lance, além da chave exclusiva do registro.

Sim, se não estiver claro que o índice concederá ao sistema geral uma melhoria de desempenho. A única consulta por mês para lances feitos por estado provavelmente não precisa de um índice específico.

Should indexes be treated as part of requirement/specification?

NÃO . Os índices são um componente do design de software. Eles não têm mais lugar em requisitos ou especificações do que o uso de um método de estrutura específico ou nome de variável transitória.

(É possível que toda ou parte da programação venha de seu cliente, mas é tolice fazer uso de tal requisito. Um servidor de indexação não tem propósito se o servidor enviar a tabela inteira de qualquer maneira.)

A criação de índices é um detalhe de implementação , não os considero parte de uma especificação. O design da sua estrutura de banco de dados geralmente envolve apenas a tabela & nomes de coluna e tipos de dados, não o DDL que será usado para criá-lo - e é aí que CREATE INDEX seria incluído.

Para a maioria das relações de tabelas complicadas, você não terá índices em todas as combinações possíveis de chaves, já que isso não faz sentido w.r.t. a lógica de negócios. Você deve criá-las no início em todas as chaves de entidade comumente usadas & JOIN s, e eu apenas uso o Explain Plan para capturar os casos de borda.

Sim, criar índices de banco de dados faz parte do design, implementação e otimização.

• Um grande conjunto de índices faz parte do design. A chave primária e os índices de chave estrangeira se enquadram nessa categoria. Chaves primárias e exclusivas são caras para impor sem um índice. Se você entender bem o design, poderá omitir alguns índices de chave estrangeira. Você também pode substituir índices com colunas adicionais para o índice de chave estrangeira. Se padrões de acesso forem bem compreendidos, índices adicionais podem ser especificados. Os índices de chave primária e chave estrangeira são essenciais para unir desempenho e otimização de consulta. O design especificará chaves e índices criados durante a implementação.
• Durante a implementação, você criará os índices resultantes do design. O modelo lógico do design pode ser modificado. Isso pode resultar em novos índices. Geralmente, a implementação deve resultar em poucos novos índices.
• Problemas de desempenho podem revelar caminhos de acesso para os quais um índice apropriado não está disponível. Um projeto ou implementação mais completo pode ter descoberto alguns desses casos. Em outros casos, o uso real ou a distribuição de dados pode diferir do que era esperado durante o design e a implementação. A distribuição de valores de escala e índice pode ter um impacto significativo no valor de um índice para uma consulta e no plano de consulta otimizado.

A adição de todos os índices de consulta que podem ser, ou espera-se que sejam, necessários no design ou no tempo de implementação seria um exagero. Cada índice carrega uma sobrecarga e muitos índices podem ser caros.

Algumas razões pelas quais um índice pode não ser útil incluem:

• O caminho de acesso é raramente ou nunca usado;
• O otimizador de consulta pode escolher um caminho de acesso diferente; ou
• Um índice parcial fornece um conjunto de registros suficientemente pequeno.