Olá pessoal, dando continuidade aos artigos sobre índices, agora abordaremos os índices no SQL Server.

Para acessar os dados dentro das tabelas, o SQL Server utiliza dois modos, o Table Scan e os índices.

No Table Scan, o SQL Server realiza uma varredura física, linha a linha, até encontrar os dados solicitados. Então se o SQL Server tiver que realizar uma varredura numa tabela inteira, linha a linha, isso significa que é ruim? Sim e não.

Devemos ao máximo evitar os table scans em um banco de dados SQL Server. Se partirmos do princípio que nosso banco de dados passou por um processo de normalização dos dados, dificilmente teremos uma tabela sem pelo menos um índice primário (PK). Mas mesmo assim, o SQL Server, poderá achar que é “menos custoso”, acessar o dado de uma tabela, realizando uma varredura física, do que ter que acessar a página de índices para recuperar a informação. Isso poderá acontecer em tabelas com pequenas quantidades de dados.

No SQL Server, temos 2 tipos de índices:
– Índices Clusterizados (Clustered Indexes)
– Índices Não Clusterizados (Nonclustered Indexes)

O índice clusterizado, é um índice gerado na própria estrutura de armazenamento dos dados, pois esse índice, fará com que os dados da sua tabela, fiquem organizados fisicamente na sequencia. Por esse motivo, só podemos ter 1 (um) índice clusterizado por tabela. E em qual coluna devemos criar índices clusterizados? Bom, por padrão, quando criamos uma PK, ela é criada automaticamente como clustered index. Porém, sempre devemos analisar caso a caso. Se para acessar os dados daquela tabela, você sempre procura os dados através da chave primária, eu recomendo que você deixe essa PK como índice clusterizado. Porém se você procura os dados daquela tabela através de uma coluna data, por exemplo, recomendo que o índice seja criado nessa coluna data. Mas veja bem, sempre temos que analisar e conhecer bem o ambiente para definirmos qual a melhor coluna para criarmos o índice clusterizado.

O índice não clusterizado, é um índice criado em uma estrutura separada dos dados físicos. São criadas páginas de índices que irão conter os apontamentos para os registros físicos. É eficiente quando precisamos ter várias maneiras de pesquisa de dados dentro de uma tabela. Por exemplo, uma tabela que contém os livros de uma livraria,armazenamos o nome do livro, o ISBN, o autor, a editora. Quando pesquisamos um livro, poderemos pesquisar por qualquer uma dessas colunas, nesse caso, precisaremos ter índices para cada uma das colunas, então criaremos índices non-clustered nessas colunas.

Legal, então depois que criamos os índices, nós teremos os acessos aos dados muito mais rápidos e não teremos mais problemas de lentidão? Errado!!! Esse é um dos maiores mitos na área de banco de dados. Os índices precisam sempre ser avaliados, desfragmentados e as vezes até recriados. No caso do SQL Server, quando criamos um índice, temos uma opção chamada Fill Factor. Esse cara determina a quantidade de espaço em branco que deveremos deixar dentro das páginas de índices, para que o SQL Server possa inserir novos apontamentos ali, respeitando a ordenação daquele índice. Mas e se não existir espaço nas páginas de índices? Ele irá criar novas paginas, porém não seguindo a ordenação, aí teremos uma fragmentação do índice. Vamos a um exemplo prático para entendimento:

Em uma biblioteca temos uma estante que armazena livros. Essa estante tem 5 prateleiras, e armazena os livros da letra A até a letra E, distribuidos uniformemente entre as prateleiras. Se não deixarmos um espaço entre as letras A e B, quando chegarem novos livros da letra A, nós seremos obrigados a colocar esses livros no próximo espaço disponível, não deixando assim uma sequencia lógica dos livros da letra A. Agora, se deixarmos um espaço vazio entre as letras A e B, quando chegarem novos livros da letra A, poderemos armazená-los sequencialmente, e assim, manter a ordem lógica dos livros. Pois então, esse espaço em branco é justamente o Fill Factor.

O Fill Factor é um fator de preenchimento das páginas de índices. Nesse caso se definirmos um fill factor = 70%, o SQL Server entenderá que deverá preencher a pagina de índices, com 70% de sua capacidade total, deixando 30% para novos apontamentos que surgirão nos inserts e updates que virão.

Beleza Léo, mas e quando for preenchido esses 30%, o SQL Server vai parar de inserir apontamentos naquele índice? Não. Aí, ele irá armazenar os novos apontamentos em uma nova página de índice ou no próximo espaço disponível que encontrar. Dessa forma teremos a fragmentação. Aí é onde entra o que citei de sempre avaliar os índices. Nessas ocasiões, deveremos desfragmentar ou reorganizar o índice, ou até mesmo recriá-lo. No momento da recriação ou reorganização, ele novamente criará páginas com no máximo 70% de preenchimento, deixando espaços para novos apontamentos que virão.

E como sei quanto tenho que colocar no fill factor? Monitorando o banco de dados. Se você tem tabelas com grandes incidências de inserts e updates, é provável que tenha que usar um valor mais baixo de fill factor, mas em tabelas estáticas, que raramente são inseridos novos dados, podemos deixar o valor do fill factor alto. Outra coisa que você precisa levar em consideração, é a janela de manutenção dos seus índices, ou seja, o período em que você pode executar rotinas de reorganização dos seus índices. Tudo isso precisa ser analisado no momento de definição do fill factor.

Espero que tenham gostado do conteúdo!!

Dúvidas, sugestões, reclamações, fiquem a vontade para enviar um e-mail para mim: leolopes@blogdati.com.br