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

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

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

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

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;

ID 列に KEY または UNIQUE KEY インデックスを追加すると、自動インクリメント機能が維持され、memberid 列が主キーになり、memberid 値に基づいた効率的なクエリが可能になります。

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

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

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

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