Inconveniente de rendimiento de la clave principal compuesta en MySQL

INSERT y UPDATE el rendimiento varía poco:será casi el mismo para (INT) y (INT, INT) llaves.

SELECT rendimiento de la PRIMARY KEY compuesta depende de muchos factores.

Si su tabla es InnoDB , entonces la tabla se agrupa implícitamente en la PRIMARY KEY valor.

Eso significa que las búsquedas de ambos valores serán más rápidas si ambos valores comprenden la clave:no se requerirá una búsqueda de clave adicional.

Asumiendo que su consulta es algo como esto:

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

y el diseño de la mesa es 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

, el motor solo necesitará buscar el valor de clave exacto en la tabla.

Si usa un campo de incremento automático como una identificación falsa:

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

, entonces el motor necesitará, primero, buscar los valores de (col1, col2) en el índice ix_mytable_col1_col2 , recupere el puntero de fila del índice (el valor de id ) y realice otra búsqueda por id en la tabla misma.

Para MyISAM tablas, sin embargo, esto no hace ninguna diferencia, porque MyISAM las tablas están organizadas en montón y el puntero de fila es solo un desplazamiento de archivo.

En ambos casos, se creará un mismo índice (para PRIMARY KEY o para UNIQUE KEY ) y se usará de la misma manera.