Estou executando uma ferramenta de indexação automática em nosso banco de dados MS SQL (modifiquei um script originário da Microsoft que analisa as tabelas de estatísticas de índice - Indexação Automática Automática ). A partir das estatísticas, agora tenho uma lista de recomendações para índices que precisam ser criados.

Editar: os índices descritos acima pegam informações das DMVs que informam o que o mecanismo de banco de dados usaria para índices, se eles estivessem disponíveis, e os scripts pegam as recomendações Top x (por buscas, impacto no usuário etc.) e as colocam em uma tabela.

(Edite acima, parcialmente retirado da resposta de Larry Coleman abaixo, para esclarecer o que os scripts estão fazendo)

Como sou novo no administrador de bancos de dados e depois de ter feito uma pesquisa rápida na rede, reluto em mergulhar e adicionar cegamente os índices recomendados. No entanto, não tendo experiência em campo, estou procurando alguns conselhos sobre como determinar se as recomendações são necessárias ou não.

Preciso executar o SQL Profiler ou é melhor examinar o código que consulta as tabelas? E você tem algum outro conselho?

Eu uso os scripts de análise de índice de Jason Strate (local antigo) . Eles informam quanto seus índices existentes são usados ​​e quanto índices ausentes seriam usados. Normalmente, não adiciono índices, a menos que eles representem mais de 5 ou 10% das consultas em uma tabela.

Mais importante, porém, é garantir que o aplicativo responda rápido o suficiente para os usuários.

Atualização: artigos do blog de análise de índice de Jason Strate para scripts mais recentes (Nova localização)

Atualização dupla: hoje em dia, uso sp_BlitzIndex® ao executar a análise de índice.

Existem alguns conceitos e termos que são importantes para entender ao lidar com índices. Pesquisas, varreduras e pesquisas são algumas das maneiras pelas quais os índices serão utilizados por meio de instruções select. A seletividade das colunas principais é essencial para determinar a eficácia de um índice.

Uma busca acontece quando o Otimizador de Consultas do SQL Server determina que a melhor maneira de encontrar os dados solicitados é verificando um intervalo em um índice. As pesquisas geralmente ocorrem quando uma consulta é "coberta" por um índice, o que significa que os predicados de busca estão na chave de índice e as colunas exibidas estão na chave ou incluídas. Uma verificação ocorre quando o SQL Server Query Optimizer determina que a melhor maneira de encontrar os dados é verificar o índice inteiro e filtrar os resultados. Uma pesquisa geralmente ocorre quando um índice não inclui todas as colunas solicitadas, na chave de índice ou nas colunas incluídas. O otimizador de consulta usará a chave em cluster (em um índice em cluster) ou o RID (em um heap) para "procurar" as outras colunas solicitadas.

Normalmente, as operações de busca são mais eficientes do que as varreduras, devido à consulta física de um conjunto de dados menor. Há situações em que esse não é o caso, como um conjunto de dados inicial muito pequeno, mas que vai além do escopo da sua pergunta.

Agora, você perguntou como determinar a eficácia de um índice e há algumas coisas a serem lembradas. As colunas de chave de um índice em cluster são chamadas de chave de cluster. É assim que os registros são tornados únicos no contexto de um índice em cluster. Todos os índices não clusterizados incluirão a chave em cluster por padrão, para executar pesquisas quando necessário. Todos os índices serão inseridos, atualizados ou excluídos de cada instrução DML respectiva. Dito isto, é melhor equilibrar os ganhos de desempenho em instruções selecionadas com os resultados de desempenho nas instruções de inserção, exclusão e atualização.

Para determinar a eficácia de um índice, você deve determinar a seletividade de suas chaves de índice. A seletividade pode ser definida como uma porcentagem de registros distintos para o total de registros. Se eu tiver uma tabela [person] com 100 registros no total e a coluna [first_name] contiver 90 valores distintos, podemos dizer que a coluna [first_name] é 90% seletiva. Quanto maior a seletividade, mais eficiente a chave de índice. Tendo em mente a seletividade, é melhor colocar as colunas mais seletivas em primeiro lugar na sua chave de índice. Usando o meu exemplo anterior [person], e se tivéssemos uma coluna [last_name] 95% seletiva? Gostaríamos de criar um índice com [last_name], [first_name] como a chave do índice.

Sei que essa foi uma resposta bastante demorada, mas realmente existem muitas coisas que determinam a eficácia de um índice e muitas coisas com as quais você deve pesar os ganhos de desempenho.

Recentemente, descobri um script gratuito fantástico das pessoas do BrentOzar Unltd http://www.brentozar.com/blitzindex/

Isso faz uma boa análise de quais índices existem, com que frequência eles são usados ​​e com que freqüência o mecanismo de consulta procura um índice que não existe.

Sua orientação geralmente é boa. Às vezes, as idéias são um pouco exageradas. Eu geralmente fiz o seguinte até agora:

• Índices removidos NUNCA foram lidos (ou talvez menos de 50 vezes por mês).
• Adicionado os índices mais óbvios em chaves e campos estrangeiros que eu sei que usamos muito.

Não adicionei todos os índices recomendados e voltei uma semana depois para descobrir que eles não são mais recomendados, pois o mecanismo de consulta está usando alguns dos outros novos índices!

Geralmente você deve evitar índices sobre:

• Tabelas muito pequenas (menos de 50 a 200 registros): geralmente o mecanismo de consulta é mais rápido se verifica a tabela em vez de carregar o índice, ler, processar etc.
• Evite índices em colunas com baixa cardinalidade ( http://en.wikipedia.org/wiki/Cardinality_(SQL_statements) ) na primeira coluna mencionada. Por exemplo, a indexação de um campo de gênero (M / F) é de pouca utilidade; é igualmente prático escanear a tabela e encontrar os ~ 50% correspondentes. Se estiver listado depois de algo mais específico no índice (por exemplo, [data de nascimento, sexo]), é melhor - você pode querer que todos os homens nascam em um determinado período de tempo.

Os índices agrupados são bons - normalmente, eles são baseados na sua chave primária. Eles ajudam o mecanismo de banco de dados a colocar os dados no disco em boa ordem. Muito essencial para entender isso nas tabelas maiores, pois um bom índice de cluster geralmente reduz o espaço que a tabela ocupa.

Reduzi algumas tabelas de 900 MB para 400 MB, apenas porque eram pilhas não estruturadas de antemão. http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx

Reorganizar / reconstruir

Você deve procurar índices fragmentados. Um pouco de fragmentação é bom, não fique obsessivo! http://technet.microsoft.com/en-us/library/ms189858.aspx Conheça a diferença entre reorganizar e recriar!

Revisar regularmente

As consultas mudam, os volumes de dados mudam, novos recursos são adicionados, os antigos removidos. Você deve procurá-los uma vez por mês (ou mais frequentemente, se tiver grandes volumes) e procurar onde você pode ajudar o banco de dados!

Quantos

Em um vídeo recente, Brent recomenda (normalmente) não mais de 5 índices em uma tabela com muita escrita (por exemplo, tabela de pedidos) e não mais que 10 se for lido muito mais do que escrito (por exemplo, tabela de registro para análise) http: / /www.youtube.com/watch?v=gOsflkQkHjg

No geral

Depende!

Sua milhagem varia de acordo com o banco de dados. Cubra o óbvio (sobrenome do funcionário, data do pedido, etc.) em suas tabelas maiores (agora / futuras). Monitore, revise e ajuste conforme necessário. Ele deve fazer parte da sua lista de verificação de rotina ao gerenciar seus bancos de dados :)

Espero que isto ajude!

Normalmente, temos uma carga de trabalho específica (consultas) e testamos cuidadosamente o impacto de cada novo índice na carga de trabalho. Esse processo iterativo deve sempre incluir uma análise cuidadosa dos planos de execução, que revelariam quais índices são usados. O tópico de analisar uma consulta é demorado, e começar com o capítulo dedicado do MSDN Analisando uma Consulta é uma boa aposta.

Às vezes, quando a carga de trabalho é muito complexa ou o conhecimento do design do banco de dados é superficial, é usado o Orientador de Otimização do Mecanismo de Banco de Dados , que faz algumas análises automáticas da sua carga de trabalho e propõe alguns índices. As propostas devem, é claro, ser cuidadosamente analisadas e o impacto deve ser medido imediatamente.

Portanto, se você seguir minha ideia, adicionar um índice e medir o impacto é realmente apenas um caso de teste A / B : você executa sua carga de trabalho sem o índice como uma linha de base e depois com o índice, mede e compara com a linha de base e decida, com base nas métricas observadas e medidas, se o impacto é benéfico. A carga de trabalho é melhor um conjunto de testes de boa qualidade, mas também pode ser uma reprodução de uma carga de trabalho capturada, consulte Como: Reproduzir um Arquivo de Rastreio .

Uma resposta mais sintética é olhar para a sys.dm_db_index_usage_statsvisualização e ver como os índices estão sendo utilizados, mas essa geralmente é uma abordagem para fazer análises no local em uma carga de trabalho desconhecida (ou seja, um consultor chamado para ajudar provavelmente começaria com isso).

A partir do SQL 2005, o SQL Server possui DMVs que informam o que o mecanismo de banco de dados usaria para índices, se estivessem disponíveis. As visualizações podem informar quais colunas devem ser colunas-chave, quais colunas devem ser incluídas e, o mais importante, quantas vezes o índice teria sido usado.

Uma boa abordagem seria classificar a consulta de índices ausentes pelo número de pesquisas e considerar adicionar os índices principais primeiro.

^{Veja também: os documentos oficiais do MS DMV}

Depende de como essa tabela é usada. por exemplo, digamos que eu tenha uma tabela que é lida várias vezes, mas atualizações e inserções são raras. Além disso, eu sempre consulta a tabela em alguma coluna de chave estrangeira. Faz sentido criar um índice (sem cluster) sobre essa chave estrangeira para acelerar as consultas de leitura. Mas a desvantagem é que, sua inserção, a atualização ficará lenta.

Existem poucas consultas estatísticas que informam quanto tempo as consultas demoram. Comece com os mais lentos. Se o predicado da consulta não tiver um índice, a criação de um ajudará.