MySQLの複合主キーパフォーマンスの欠点

INSERT およびUPDATE パフォーマンスはほとんど変わりません。(INT)でもほぼ同じです。 および(INT, INT) キー。

SELECT 複合PRIMARY KEYのパフォーマンス 多くの要因に依存します。

テーブルがInnoDBの場合 、次に、テーブルはPRIMARY KEYで暗黙的にクラスター化されます 値。

つまり、両方の値がキーを構成している場合、両方の値の検索が高速になります。追加のキー検索は必要ありません。

クエリが次のようなものであると仮定します：

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

テーブルのレイアウトは次のとおりです：

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

、エンジンはテーブル自体の正確なキー値を検索する必要があります。

自動インクリメントフィールドを偽の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

、次に、エンジンは最初に(col1, col2)の値を検索する必要があります インデックス内ix_mytable_col1_col2 、インデックス（idの値）から行ポインタを取得します ）そしてidで別のルックアップを行います テーブル自体にあります。

MyISAMの場合 ただし、MyISAMであるため、テーブルに違いはありません。 テーブルはヒープで編成され、行ポインタはファイルオフセットにすぎません。

どちらの場合も、同じインデックスが作成されます（PRIMARY KEYの場合） またはUNIQUE KEY ）そして同じように使用されます。