Desvantagem de desempenho de chave primária composta no MySQL

INSERT e UPDATE o desempenho varia pouco:será quase o mesmo para (INT) e (INT, INT) chaves.

SELECT desempenho da PRIMARY KEY composta depende de muitos fatores.

Se sua tabela for InnoDB , a tabela será agrupada implicitamente na PRIMARY KEY valor.

Isso significa que as pesquisas por ambos os valores serão mais rápidas se ambos os valores incluírem a chave:nenhuma pesquisa de chave extra será necessária.

Supondo que sua consulta seja algo assim:

SELECT  *
FROM    mytable
WHERE   col1 = @value1
        AND col2 = @value2

e o layout da mesa é este:

CREATE TABLE mytable (
        col1 INT NOT NULL,
        col2 INT NOT NULL,
        data VARCHAR(200) NOT NULL,
        PRIMARY KEY pk_mytable (col1, col2)
) ENGINE=InnoDB

, o mecanismo precisará apenas pesquisar o valor exato da chave na própria tabela.

Se você usar um campo de autoincremento como um ID falso:

CREATE TABLE mytable (
        id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
        col1 INT NOT NULL,
        col2 INT NOT NULL,
        data VARCHAR(200) NOT NULL,
        UNIQUE KEY ix_mytable_col1_col2 (col1, col2)
) ENGINE=InnoDB

, o mecanismo precisará, primeiro, pesquisar os valores de (col1, col2) no índice ix_mytable_col1_col2 , recupera o ponteiro de linha do índice (o valor de id ) e faça outra pesquisa por id na própria tabela.

Para MyISAM tabelas, no entanto, isso não faz diferença, porque MyISAM as tabelas são organizadas em pilha e o ponteiro de linha é apenas o deslocamento do arquivo.

Em ambos os casos, um mesmo índice será criado (para PRIMARY KEY ou para UNIQUE KEY ) e será usado da mesma maneira.