A ordem de criação de colunas para uma tabela afeta o desempenho?

Question

Por razões puramente asméticas, sempre tive a (s) primeira (s) coluna (s) de uma tabela como coluna (s) de chave primária (s). Depois disso, eu não tomei nenhum cuidado com as colunas de pedidos que foram adicionadas à tabela. Isso está errado?

Existe um benefício de desempenho para colocar colunas inteiras na tabela antes de texto ou colunas binárias? Ou talvez colunas indexadas primeiro?

Enquanto o banco de dados atual com o qual estou trabalhando é o MySQL, as respostas para outros bancos de dados seriam úteis.

    

Answer 1

Is this wrong?

Não, eu faço o mesmo - principalmente porque uma tabela sempre começa com o PK.

Is there a performance benefit to place say integer columns in the table before text or binary columns? Or maybe indexed columns first?

Não no SQL Server. Se estiver no MySQL, seria uma confusão de grandes proporções, a menos que a sobrecarga seja REALMENTE pequena. Índices vivem separados das mesas. Ao longo da vida útil de um banco de dados, colunas indexadas e até colunas existentes podem ser alteradas.

    

Answer 2

Na verdade, para cargas realmente quentes , isso pode ter um impacto significativo. Se você olhar para a Anatomia de um registro você verá que as colunas seguem o cabeçalho do registro, a coluna fixa primeiro seguida pelas de comprimento variável. Portanto, sempre que uma coluna é acessada, o cabeçalho do registro terá que ser acessado primeiro e esse acesso é quase sempre um erro de cache L2. Qualquer acesso subseqüente dentro da mesma linha de cache (64 bytes) será um cache L2 atingido quase 100% das vezes. Dado que a diferença no ciclo da CPU entre um erro de cache L2 e um acerto é de aproximadamente 2 ordens de magnitude, você obtém um grande aumento de desempenho se organizar as colunas acessadas com frequência perto do cabeçalho do registro. O aumento de desempenho de ponta a ponta não será em qualquer lugar 2 ordens de grandeza, mas para certas cargas OLTP pode adicionar até 5-10% no total. Para cargas analíticas, o custo de IO sobrecarrega todo o resto e você provavelmente não será capaz de medir qualquer diferença.

Essa lógica é aplicada a todos os índices individualmente, mas em índices você deve considerar que a ordem de declarar o índice é a ordem real da chave para que você não tenha muito espaço para mudanças .

    

Answer 3

Eu diria que no SQL Server não importa. O SQL Server lê em páginas inteiras e não tenho certeza se o processamento para chegar à terceira coluna em uma página é mais do que o segundo ou quinto, ou qualquer outra coisa.

Não importa para a tabela, mas para o índice. A primeira coluna no índice deve estar na cláusula WHERE para o índice a ser usado.