MySQL の主キーでなくても自動インクリメント列は存在できますか?

不正なテーブル定義エラーへの対処: 自動インクリメントと主キーのバランスをとる

このシナリオには、ID 列が視覚的な自動インクリメント フィールドとして機能する MySQL テーブルが含まれます。 memberid 列は実際の一意のキーとして機能します。ただし、PRIMARY KEY (memberid) を使用してテーブルを定義しようとすると、自動列は 1 つだけであり、キーである必要があることを示すエラー (1075) が発生します。

エラーの解決: 自動インクリメントの保持および Unique Key

この問題を解決するには、インデックス (キー) が定義されていれば、PRIMARY KEY ではない自動インクリメント列を使用できます。変更されたテーブル定義は次のとおりです。

<code class="sql">CREATE TABLE members (
  id int(11) UNSIGNED NOT NULL AUTO_INCREMENT,
  memberid VARCHAR(30) NOT NULL,
  `time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  firstname VARCHAR(50) NULL,
  lastname VARCHAR(50) NULL,
  PRIMARY KEY (memberid),
  KEY (id)                          # or: UNIQUE KEY (id)
) ENGINE = MYISAM;</code>

id 列に KEY または UNIQUE KEY インデックスを追加すると、自動インクリメント機能が維持され、memberid 列が主キーになり、 memberid value.

最適なアプローチの選択: パフォーマンスと容量のバランス

最適な選択は、パフォーマンスとディスク容量の相対的な重要性によって異なります。パフォーマンスが最も重要な場合は、自動インクリメント ID 列を維持し、memberid のインデックスを使用するとバランスが取れます。

• 自動インクリメント ID により、効率的な並べ替えと範囲クエリが提供されます。
• memberid のインデックスにより、一意のメンバー ID を使用した迅速な検索が保証されます。

ただし、ディスク容量が重要な問題である場合は、id 列を完全に削除し、主キーと auto の両方として memberid 列を利用することを検討してください。 -増加フィールド。このアプローチでは、スペース利用率を向上させるためにパフォーマンスがある程度犠牲になります。最終的に、パフォーマンスとスペースのどちらを選択するかは、アプリケーションの特定の要件によって決まります。

以上がMySQL の主キーでなくても自動インクリメント列は存在できますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。