none
Tabela com muitos índices - restruturar? RRS feed

  • Pergunta

  • Ola, pessoal

    estava visitando um tópico antigo:

    https://social.msdn.microsoft.com/Forums/pt-BR/360f0552-7971-4bf7-b599-c22674f43758/vrias-tabelas-ou-poucas-tabelas-com-muitos-dados?forum=520


    Nele há uma discussão sobre modelagem, se "o melhor" para performance seria criar vários campos numa mesma tabela, ou seria melhor segmentar. Claro que não há uma resposta final, vai depender de cada caso. Mas a breve discussão valeu bastante.

    ---

    Eu estava pensando em alguns critérios, em um BD que temos num sistema, e levanto questões:

    1. Impacto de muitos índices:

    Por exemplo, uma tabela de movimentações (notas, cupons fiscais, etc) recebe dados de vários tipos (entrada de fornecedores, emissão de notas fiscais, cupons fiscais), e como o sistema é bem abrangente em termos de negócios, a tabela acaba tendo muitos campos que são foreign Key.

    - Para cada foreign key há um índice.

    - Atualmente a quantidade de índices da tabela é 28, contando com a PK.

    Eu acho que é um número grande, sendo uma tabela com grande quantidade de inserts, e tende a crescer bastante. mas não sei ao certo se isso (por si só) pode influenciar no desempenho. Não tenho conhecimento e argumentos para afirmar "é muito" ou não.

    Esse número tende a crescer com o tempo, se continuarmos com essa abordagem

    Por outro lado, essa tabela também tem muitas consultas, com joins entre ela e as foreign keys, para pegar dados de outras tabelas.

    Considerando este número de 28 índices, de forma absoluta, teria algum impacto por si só?

    Como poderia mensurar isso?

    ---

    2. Segmentar ou não:

    Se fosse pensar em segmentar a tabela "para cada ramo de negócio" por exemplo, penso também em outros problemas, por exemplo, poderia pensar em uma tabela 1 - 1 com dados referentes ao ramo X (em que as informações seriam inseridas apenas quando a movimentação fosse referente a esse ramo), reduziria o número de índices em cada tabela, consequentemente, seria em tese melhor para a inserção de dados, e até mesmo tamanho da tabela.

    Porém, há campos que ficariam na tabela "principal", por exemplo, valores, cliente, enfim, informações gerais da NF. Então seria necessário Joins, o que pode impactar nas consultas.

    Há alguma suposição de "melhor/pior" , e como lidar com este cenário em específico?

    3. Melhorar com mais índices:

    Atualmente não temos índices filtrados, e muito poucos índices com campos adicionados. Estou analisando algumas consultas que essas funcionalidades podem ser úteis, para melhorar a performance. Então, número de índices tende a crescer, e como se sabe, os índices com campos incluídos ocupam mais espaço e a manutenção é mais pesada ainda.

    Tenho receio de continuando com essa abordagem de "tabelão" venha a ter problemas no futuro (próximo).

    Dentro disso, há alguma recomendação, em termos de modelagem?

    Como poderia medir e quantificar isso?

    Obrigado!!


    Julio C.

    sábado, 4 de julho de 2020 14:17

Todas as Respostas

  • Julio,

    Vamos por partes, estamos falando especificando de uma única tabela ou de uma forma geral?

    Por padrão não devemos ter eu uma única tabela todas as colunas com índices.

    No que se refere a medir e quantificar precisamos conhecer o seu ambiente.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    segunda-feira, 6 de julho de 2020 22:39
  • Julio,

    Vamos por partes, estamos falando especificando de uma única tabela ou de uma forma geral?

    Por padrão não devemos ter eu uma única tabela todas as colunas com índices.

    No que se refere a medir e quantificar precisamos conhecer o seu ambiente.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    "Por padrão nao devemos.." que padrao??!!!
    terça-feira, 7 de julho de 2020 10:26
  • Ola, pessoal

    estava visitando um tópico antigo:

    https://social.msdn.microsoft.com/Forums/pt-BR/360f0552-7971-4bf7-b599-c22674f43758/vrias-tabelas-ou-poucas-tabelas-com-muitos-dados?forum=520


    Nele há uma discussão sobre modelagem, se "o melhor" para performance seria criar vários campos numa mesma tabela, ou seria melhor segmentar. Claro que não há uma resposta final, vai depender de cada caso. Mas a breve discussão valeu bastante.

    ---

    Eu estava pensando em alguns critérios, em um BD que temos num sistema, e levanto questões:

    1. Impacto de muitos índices:

    Por exemplo, uma tabela de movimentações (notas, cupons fiscais, etc) recebe dados de vários tipos (entrada de fornecedores, emissão de notas fiscais, cupons fiscais), e como o sistema é bem abrangente em termos de negócios, a tabela acaba tendo muitos campos que são foreign Key.

    - Para cada foreign key há um índice.

    - Atualmente a quantidade de índices da tabela é 28, contando com a PK.

    Eu acho que é um número grande, sendo uma tabela com grande quantidade de inserts, e tende a crescer bastante. mas não sei ao certo se isso (por si só) pode influenciar no desempenho. Não tenho conhecimento e argumentos para afirmar "é muito" ou não.

    Esse número tende a crescer com o tempo, se continuarmos com essa abordagem

    Por outro lado, essa tabela também tem muitas consultas, com joins entre ela e as foreign keys, para pegar dados de outras tabelas.

    Considerando este número de 28 índices, de forma absoluta, teria algum impacto por si só?

    Como poderia mensurar isso?

    ---

    2. Segmentar ou não:

    Se fosse pensar em segmentar a tabela "para cada ramo de negócio" por exemplo, penso também em outros problemas, por exemplo, poderia pensar em uma tabela 1 - 1 com dados referentes ao ramo X (em que as informações seriam inseridas apenas quando a movimentação fosse referente a esse ramo), reduziria o número de índices em cada tabela, consequentemente, seria em tese melhor para a inserção de dados, e até mesmo tamanho da tabela.

    Porém, há campos que ficariam na tabela "principal", por exemplo, valores, cliente, enfim, informações gerais da NF. Então seria necessário Joins, o que pode impactar nas consultas.

    Há alguma suposição de "melhor/pior" , e como lidar com este cenário em específico?

    3. Melhorar com mais índices:

    Atualmente não temos índices filtrados, e muito poucos índices com campos adicionados. Estou analisando algumas consultas que essas funcionalidades podem ser úteis, para melhorar a performance. Então, número de índices tende a crescer, e como se sabe, os índices com campos incluídos ocupam mais espaço e a manutenção é mais pesada ainda.

    Tenho receio de continuando com essa abordagem de "tabelão" venha a ter problemas no futuro (próximo).

    Dentro disso, há alguma recomendação, em termos de modelagem?

    Como poderia medir e quantificar isso?

    Obrigado!!


    Julio C.

    Esse eh um tabelao franqueistein neh?

    teste indice filtrado para foreign key.

    terça-feira, 7 de julho de 2020 10:34
  • Julio,

    Vamos por partes, estamos falando especificando de uma única tabela ou de uma forma geral?

    Por padrão não devemos ter eu uma única tabela todas as colunas com índices.

    No que se refere a medir e quantificar precisamos conhecer o seu ambiente.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    "Por padrão nao devemos.." que padrao??!!!

    Avatar,

    Da uma olhadinha nestes links: https://docs.microsoft.com/pt-br/sql/relational-databases/indexes/create-indexes-with-included-columns?view=sql-server-ver15

    https://docs.microsoft.com/pt-br/sql/relational-databases/sql-server-index-design-guide?view=sql-server-ver15

    Este outro que não é oficial, também ilustra bem os conceitos sobre índices:

    https://pt.stackoverflow.com/questions/76131/quando-e-em-quais-colunas-deve-se-usar-%C3%ADndices

    Já este outro do meu amigo Dirceu Resende é bem interessante:

    https://www.dirceuresende.com/blog/entendendo-o-funcionamento-dos-indices-no-sql-server/



    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]


    terça-feira, 7 de julho de 2020 17:22
  • Julio,

    Vamos por partes, estamos falando especificando de uma única tabela ou de uma forma geral?

    Por padrão não devemos ter eu uma única tabela todas as colunas com índices.

    No que se refere a medir e quantificar precisamos conhecer o seu ambiente.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    "Por padrão nao devemos.." que padrao??!!!

    Avatar,

    Da uma olhadinha nestes links: https://docs.microsoft.com/pt-br/sql/relational-databases/indexes/create-indexes-with-included-columns?view=sql-server-ver15

    https://docs.microsoft.com/pt-br/sql/relational-databases/sql-server-index-design-guide?view=sql-server-ver15

    Este outro que não é oficial, também ilustra bem os conceitos sobre índices:

    https://pt.stackoverflow.com/questions/76131/quando-e-em-quais-colunas-deve-se-usar-%C3%ADndices

    Já este outro do meu amigo Dirceu Resende é bem interessante:

    https://www.dirceuresende.com/blog/entendendo-o-funcionamento-dos-indices-no-sql-server/



    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]


    Se vc leu tudo q indicou entao pode dizer onde esta escrito q "Por padrão não devemos ter eu uma única tabela todas as colunas com índices"? Nunca vi isso... 

    terça-feira, 7 de julho de 2020 18:04
  • Julio,

    Vamos por partes, estamos falando especificando de uma única tabela ou de uma forma geral?

    Por padrão não devemos ter eu uma única tabela todas as colunas com índices.

    No que se refere a medir e quantificar precisamos conhecer o seu ambiente.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    "Por padrão nao devemos.." que padrao??!!!

    Avatar,

    Da uma olhadinha nestes links: https://docs.microsoft.com/pt-br/sql/relational-databases/indexes/create-indexes-with-included-columns?view=sql-server-ver15

    https://docs.microsoft.com/pt-br/sql/relational-databases/sql-server-index-design-guide?view=sql-server-ver15

    Este outro que não é oficial, também ilustra bem os conceitos sobre índices:

    https://pt.stackoverflow.com/questions/76131/quando-e-em-quais-colunas-deve-se-usar-%C3%ADndices

    Já este outro do meu amigo Dirceu Resende é bem interessante:

    https://www.dirceuresende.com/blog/entendendo-o-funcionamento-dos-indices-no-sql-server/



    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]


    Se vc leu tudo q indicou entao pode dizer onde esta escrito q "Por padrão não devemos ter eu uma única tabela todas as colunas com índices"? Nunca vi isso... 

    Avatar,

    Sim, eu li todos os posts, inclusive utilizo em minhas aulas.

    Se você nunca leu, ou nunca viu isso, talvez seja interessante fazer alguns testes.

    Tenho a certeza que você conhece os limites de armazenamento de dados aplicados para os índices criados em nossas tabelas.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    terça-feira, 7 de julho de 2020 21:42
  • ...mas nao encontrou nada q comprove "Por padrão não devemos ter eu uma única tabela todas as colunas com índices"

    se tivesse encontrado teria postado.

    nao postou pq nao existe isso


    • Editado Avatar SQL segunda-feira, 13 de julho de 2020 12:30
    segunda-feira, 13 de julho de 2020 11:40
  • Olá Avatar,

    Até concordo com vc que  não existe esta 'regra'. 

    Dificilmente durante a modelagem iremos achar indices para todas as colunas .  Mas, isto pode sim acontecer e parece ser esta a situação.  Mas, normalmente quando isto ocorre é devido ao desenvolvedor simplesmente achar que deve colocar indice em tudo pois melhora as queries e não por uma análise profunda do problema. 

    Enfim, talvez no ambiente do amigo tenham muitos indices mesmo mas, falar sem conhecer o ambiente acaba sendo 'orelhada'. 

    Sabemos que muitos indices vão impactar nas inserções e atualizações (muito pouco , mas, vão e dependendo do ambiente...) Mas, vão dar retorno interessante nas leituras. 

    Agora , é ver a situação do embiente rsrs.


    Se esta resposta lhe ajudou, marque-a como útil para que outra pessoa com dúvida ou problema semelhante possa encontrar resposta ou ajuda mais facilmente. * Jefferson Clyton Pereira da Silva - [ MCSA | MCP | MCTS | MTA | Analista de Banco de Dados - Sql Server e Oracle ]

    terça-feira, 28 de julho de 2020 04:41