Herdei um banco de dados em que muitas das tabelas têm bigint como tipo de dados para muitos dos campos, e quando você vê o conteúdo ele não exige todo o espaço que o bigint oferece. O uso de bigint para campos que não precisam afeta o desempenho do banco de dados?
Usar
bigint
comparado aint
tem, pelo menos, estas desvantagens de desempenho em potencial:Dito isto, o impacto prático que essas coisas têm para você depende muito de seu ambiente e carga de trabalho específicos.
Observação: os aumentos nos problemas de uso de disco e RAM podem ser atenuados usando a compactação de linha , ao custo de maior uso da CPU. Como os servidores geralmente têm mais sobrecarga de CPU do que a RAM, isso geralmente é uma boa compensação (graças a Andy por este lembrete!)
Sim, o desempenho foi afetado.
Na fase de otimização, o otimizador de consulta usa 50% do tamanho dos dados por coluna para estimar o tamanho dos dados da linha. Se usarmos tipos de dados maiores para colunas que armazenam dados menores, o tamanho estimado dos dados provenientes de tabelas será maior e causará maior exigência de concessão de memória ideal para consultas.
O excesso de concessão de memória estimada causa pressão de memória para o SQL Server e afeta mal a expectativa de vida da página (diminua). O valor PLE mais baixo significa que as páginas de dados lidas do disco são armazenadas em cache na memória (RAM) por um período mais curto.
Para evitar problemas de desempenho, todas as colunas de comprimento variável, variáveis locais e parâmetros devem ser projetados adequadamente. Podemos usar int em vez de bigint para uma coluna de identidade e definir -2.147.483.648 como valor inicial para obter o benefício de tamanho duplo do tipo de dados int.