Quando usar TINYINT sobre INT?

O espaço em disco é barato... esse não é o ponto!

Pare de pensar em termos de espaço de armazenamento, pense em buffer pool e largura de banda de armazenamento . No extremo, cache da CPU e largura de banda do barramento de memória . O artigo vinculado faz parte da série que destaca problemas com a seleção de chaves clusterizadas inadequadas (INT vs GUID vs GUID Sequencial), mas destaca a diferença que os bytes podem fazer.

A mensagem principal é a questão do design. A diferença não aparecerá em um banco de dados individual em um servidor adequadamente especificado até que você atinja o território VLDB, mas se você puder economizar alguns bytes, por que não fazê-lo.

Lembro-me do ambiente descrito em uma pergunta anterior . Mais de 400 bancos de dados, variando em tamanho de 50 MB a 50 GB, por instância SQL. Limpar alguns bytes por registro, por tabela, por banco de dados nesse ambiente pode fazer uma diferença significativa.

Além das outras respostas...

As linhas e entradas de índice são armazenadas em 8k páginas. Portanto, um milhão de linhas a 3 bytes por linha não é 3 MB no disco: afeta o número de linhas por página ("densidade da página").

O mesmo se aplica a nvarchar para varchar, smalldatetime para datetime, int para tinyint etc

Editado, junho de 2013

http://sqlblog.com/blogs/joe_chang/archive/2013/06/16/load-test-manifesto.aspx

Este artigo afirma

Os critérios importantes são a cardinalidade e a proporção de página para linha.

Portanto, a escolha do tipo de dados importa

Não é apenas o armazenamento de tabela que é considerado. Se você usa índices em que a coluna int faz parte de uma chave composta, naturalmente deseja que as páginas de índice sejam o mais completas possível, sendo isso o resultado de as entradas de índice serem as menores possíveis.

Eu definitivamente esperaria descobrir que examinar entradas de índice em páginas BTREE seria um pouco mais rápido com tipos de dados menores. No entanto, quaisquer VARCHARs envolvidos em entradas de índice compensariam (anulariam) os ganhos de desempenho do uso de TINYINT sobre INT.

Não obstante, se as entradas de índice tiverem entradas compostas e todas forem números inteiros, quanto menores forem os números inteiros, melhor e mais rápido.

Todas as coisas se tornam complexas quando os bancos de dados ficam maiores:

• as janelas de manutenção precisam ser ampliadas ou reprogramadas
• backups (o backup completo no final do dia se torna um consumidor de tempo absurdo, então você precisa de backups diferenciais ou mesmo de log e faça o backup completo uma vez por semana, talvez uma vez por mês)
• performances manutenções se torna um consumidor de tempo (criar um índice em uma tabela de vários milhões de linhas não leva um tempo trivial para ser executado) e precisa ser reprogramado e fica pior se a tabela for grande ...
• E transmitir esse backup de 100Gb pela rede não é o que eu chamo de moleza - especialmente se a rede (por algum motivo desconhecido) for teimosa em deixar cair a conexão na marca de 75Gb... (aconteceu com uma instalação que eu estava trabalhando nisso estava fazendo backup em uma unidade mapeada na rede)...

E que tipos de dados têm a ver com isso? TUDO. O uso de tamanhos de linha maiores do que o necessário faz com que as páginas do banco de dados sejam preenchidas antes do necessário ou até mesmo desperdiçando espaço se o tamanho da linha for tal que não seja possível gravar mais de um registro na página. O resultado é mais páginas necessárias para serem escritas e lidas, mais memória RAM é usada para armazenar em cache (registros maiores precisam de mais memória). E como seus tipos de dados são especificados maiores do que o necessário do disco, seus índices sofrerão o mesmo problema - especialmente se você agrupar essa chave primária composta de 2 colunas BIGINT, pois quaisquer outros índices criados copiarão essa chave primária implicitamente em sua definição.

Se você sabe que algumas colunas em uma tabela que terá milhões de linhas ou até mesmo uma pequena tabela que será FK'ed para vários milhões de linhas que não precisa de um inteiro de 4 bytes para armazenar seus dados, mas um de 2 bytes seria basta - use SMALLINT . Se os valores no intervalo de 0 a 255 forem suficientes, TINYINT . Uma bandeira Sim/Não? Tem BIT .

Enquanto para tinyintvs intexistem diferenças claras, como espaço em disco, divisões de página e tempo de manutenção, não haveria nenhuma delas para varchar.

Então, por que não declarar todos os campos de texto como varchar(4000), já que ele usará apenas o espaço necessário? Ainda mais você terá a garantia de que seus dados nunca serão truncados.

A resposta é claro:

1. Esclarecimento de suas intenções (já que ninguém entenderá por que um campo de nome deve ter 4.000 caracteres)
2. Validação, pois você deseja garantir que ninguém insira uma biografia inteira como nome.

Essas mesmas razões se aplicam tinyinttambém.