現在、それぞれ 3 つの列を持つ 2 つのテーブルを持つデータベースがあります。
テーブル A : id, uid,url
テーブル_B : id, uid,url
は、新しい行が挿入されるたびにid自動的にインクリメントされる主キーです。1
私が持っている質問は、まだ主キーが必要かということです。のデータベースにクエリを実行することはありませんid。uid列は単純にユーザーごとに区切られるため、行ごとに一意ではありません
。Table_AとTable_Bよく比較されuidます。私はインデックスを作成しており、テーブルが数十億単位で成長する可能性があると予想しておりuid、.urlid
InnoDB を使用し、主キー列を宣言しない場合、InnoDB は 6 バイトの整数を使用して作成します。したがって、id 列を削除することで得られる唯一のことは、おそらく 8 バイトの BIGINT を 6 バイトの暗黙の PK 列と交換することです。
その理由は、 InnoDB テーブルが B ツリー (主キーに基づくクラスター化インデックス) として格納されるためです。すべてのテーブルには、暗黙的に作成された列であっても、この B ツリーを編成するために使用する列が必要です。
複合主キーを使用してテーブルを宣言することもできます。
CREATE TABLE Table_A (
uid INT NOT NULL,
url VARCHAR(100) NOT NULL,
PRIMARY KEY (uid, url)
);
この場合、主キーの要件は満たされ、 InnoDB は暗黙的な列を作成しません。
あなたのコメントについて:
MyISAM を使用しないようにしています。MyISAM は InnoDB よりもデータ破損の影響を受けやすく、データとインデックスの両方をキャッシュするため、通常は InnoDB のパフォーマンスが向上します。確かに、MyISAM がより少ないディスク容量を使用できる場合もありますが、ディスク容量は安価であり、むしろ InnoDB のメリットを得たいと考えています。
インデックスに関してPRIMARY KEY(uid, url)は、これらの 2 つの列に自動的に複合インデックスが作成されます。uid に追加のインデックスを作成する必要はありません。
ただし、特定の uid を検索せずに url のみを検索するクエリがある場合は、url に別のインデックスが必要です。
インデックスの設計については、次のプレゼンテーションで詳しく説明しています。
技術的にはいいえ。ただし、これは良い習慣であり、将来の要件がどうなるかはわかりません。一意のid列が必要になり、それがない場合は、大きな頭痛の種になる可能性があります。列で「無駄になった」オーバーヘッドの量はid、私の意見では絶対に価値があります。
さらに、 と の間の関係によっては、Table_AそれらTable_bの間の関係を定義するための中間テーブルが必要になる場合があります (例: one-to-nany、many-to-many)。このようなシナリオで非常に効率的なクエリを実行するには、一意のid列が必要になります。
列は必要ありませんがid、「主」キーはuid-url