Composite Primary Key prestatie nadeel in MySQL

INSERT en UPDATE prestatie varieert weinig:het zal bijna hetzelfde zijn voor (INT) en (INT, INT) toetsen.

SELECT prestatie van samengestelde PRIMARY KEY hangt van veel factoren af.

Als uw tabel InnoDB is , dan is de tabel impliciet geclusterd op de PRIMARY KEY waarde.

Dat betekent dat het zoeken naar beide waarden sneller gaat als beide waarden de sleutel vormen:er is geen extra sleutelzoekopdracht vereist.

Ervan uitgaande dat uw vraag ongeveer als volgt is:

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

en de tafelindeling is als volgt:

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

, hoeft de engine alleen de exacte sleutelwaarde in de tabel zelf op te zoeken.

Als u een autoincrement-veld gebruikt als een nep-ID:

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

, dan moet de engine eerst de waarden opzoeken van (col1, col2) in de index ix_mytable_col1_col2 , haal de rijaanwijzer op uit de index (de waarde van id ) en zoek nog een keer op met id in de tabel zelf.

Voor MyISAM tabellen maakt dit echter geen verschil, omdat MyISAM tabellen zijn op een hoop geordend en de rijaanwijzer is slechts een bestandsverschuiving.

In beide gevallen wordt dezelfde index gemaakt (voor PRIMARY KEY of voor UNIQUE KEY ) en zal op dezelfde manier worden gebruikt.