テーブル1には、id（autoincrement）、citynumber（unique）、description（varchar（1000））の3つの列があります。 カラムIDはクエリで使用されません。これはちょうど私の便宜のために使用されています（テーブルがどのように成長するかを見るために、idを参照するのはcitynumberよりも簡単ですが、idはSQLクエリを作成するときに使用されません）。MySQL：追加のid列とパフォーマンスの比較
パフォーマンスを向上させるには、id列を削除することを強くお勧めしますか？
idカラムを削除しても、パフォーマンスは向上しません。少なくとも、賢明な方法ではありません。同じディスクを保存することしかできません。その上、PKがあなたに与えることができる利点は、通常、スペースを節約するよりずっと優れています。
いいえ、ID列はほとんど常に存在します。テーブルを追加して参加したい場合は、IDカラムが便利です。それはパフォーマンスに全く影響を与えてはならず、わずかなスペース消費量の差にすぎません。
パフォーマンスはクエリによって異なります。 citynumberが本当にユニークであれば（自然なキーですか？）、その列にインデックスを置くと、それが結合またはフィルタリングしている場合に大きく役立ちます。
これは議論の対象となっていることが分かりました。一般に、テーブルにインデックスを付けておくことは、ルック・テーブルであっても有効です。私の意見は、インデックスを持たないレガシーコードとデータベーステーブルで働いており、後で必要となります。はい、これはマイナーな更新ステートメントですが、データベースはそれに応じてすべてのインデックスを再作成する必要があり、この更新中のパフォーマンスに影響する可能性があります。
私の意見です。
データベースに実際の（架空ではない）都市のみを格納すると仮定すると、パフォーマンスについてまったく気にすることなく、世界の都市すべてを簡単に保存できます。
InoDBは、PKがデータを指し、ユニークなポイントをPKに、それ以降はデータのみを指すため、ユニークインデックスよりも速く動作します。
したがって、idを削除し、citynumberを主キーにします。
スティル、それはあなたに多くのパフォーマンスの改善を与えるつもりはありません。
'unique'制約とPKsの間にあなたのポイントを置くと、 'id'カラムを削除する理由はありません。サロゲートキーピアをナチュラルキーに代入すると便利です。 where句がcitynumberカラムにフィットする場合でも、代理のPKに対する継承は可能です。 – dlgrasse
なぜsurogate PKに対してジョインを使用しますか？私がこの投稿から理解するところでは、idとcitynumberのデータ型は同じである可能性があります。 – Oroboros102
である可能性があります。私は都市番号が自然なキーであるかどうか私の答えで尋ねてきましたが、応答はありませんでした。サロゲートに参加する理由については、私はそれが彼らのためにあると答えています。定義上、彼らはdb目的のためだけに存在し、外部の意味を持たなくてはなりません。 – dlgrasse