Índices agrupados versus índices não agrupados?

Question

Eu estou encarregado de um banco de dados menor de 300 bilhões de megas, com cerca de 45 usuários atingidos ao longo do dia de trabalho. Principalmente lê, mas um bom número de atualizações e inserções. Eu tenho desacelerado aprendendo a estrutura do banco de dados para obter algum desempenho com isso. Ouvi dizer que dar uma olhada nos índices é um bom lugar para começar. Todos os índices para todas as tabelas do DB são agrupados, alguns deles não são agrupados.

Existe alguma vantagem de velocidade em relação a cluster versus não cluster? Eu tenho um plano de manutenção (sim, sim, eu sei) que reorganiza e reconstrói os índices todas as noites antes dos diff backups, isso é bom o suficiente por enquanto, até eu conseguir uma melhor aderência na formação e utilização do índice?

Existem roteiros que me ajudem a ver o desempenho dos vários índices? Quão grande de lata de minhocas eu consegui entrar?

    

Answer 1

Um índice agrupado determina a ordem física dos dados em uma tabela e é particularmente eficiente em colunas que são frequentemente pesquisadas por intervalos de valores. Eles também são eficientes para encontrar uma linha específica quando o valor indexado é único.

Normalmente (há exceções), o índice clusterizado deve estar em uma coluna que aumenta monotonicamente - como uma coluna de identidade ou alguma outra coluna onde o valor está aumentando - e é exclusiva. Em muitos casos, a chave primária é a coluna ideal para um índice clusterizado (mas não coloque um índice clusterizado em uma coluna uniqueidentifier / GUID).

Deste artigo do MSDN :

Before creating clustered indexes, understand how your data will be accessed. Consider using a clustered index for:

• Columns that contain a large number of distinct values.
• Queries that return a range of values using operators such as BETWEEN, >, >=, <, and <=.
• Columns that are accessed sequentially.
• Queries that return large result sets.
• Columns that are frequently accessed by queries involving join or GROUP BY clauses; typically these are foreign key columns. An index on the column(s) specified in the ORDER BY or GROUP BY clause eliminates the need for SQL Server to sort the data because the rows are already sorted. This improves query performance.
• OLTP-type applications where very fast single row lookup is required, typically by means of the primary key. Create a clustered index on the primary key.

Clustered indexes are not a good choice for:

• Columns that undergo frequent changes: This results in the entire row moving (because SQL Server must keep the data values of a row in physical order). This is an important consideration in high-volume transaction processing systems where data tends to be volatile.
• Wide keys: The key values from the clustered index are used by all nonclustered indexes as lookup keys and therefore are stored in each nonclustered index leaf entry.

SQLServerpedia.com tem alguns bons artigos / tutoriais para ajuste de índice: Consultas DMV relacionadas ao índice e Usando os índices corretos para desempenho ideal .

    

Answer 2

Eu li que é uma prática muito boa usar uma chave substituta & use um índice clusterizado nessa coluna. Normalmente, essa será uma coluna int que fará o incremento automático (IDENTITY) ou um identificador exclusivo (tornará um GUID sequencial para evitar problemas de desempenho mais tarde!).

Ao fazer isso, suas consultas farão JOINs nessas chaves substitutas em todas as tabelas, oferecendo desempenho & escalabilidade.

No que diz respeito a outros índices (não agrupados em cluster), essa escolha depende de como seus clientes usam seu aplicativo. Muitos índices soletram desastre para inserções / atualizações. Índices insuficientes diminuem as leituras. Você precisará encontrar um equilíbrio entre os dois. As colunas usadas em conjunto com pesquisas são candidatos lógicos para indexação, incluindo índices compostos (várias colunas) (observe a ordem das colunas, nesse caso).

Se você deseja obter uma fantasia, tenha um banco de dados OLAP separado para gerar relatórios sobre dados históricos.