5

'projects'私のテーブルの各エントリには、 varchar(32).

これを として使用するのは悪い習慣と見なされprimary keyますか? 主キーの推奨サイズ、データ型はありますか?

4

6 に答える 6

5

はい、主キーにこのような大きな列を使用するのは悪い考えです。その理由は、そのテーブルに作成するすべてのインデックスに 32 文字の列が含まれるため、すべてのインデックスのサイズが肥大化するためです。インデックスが大きいほど、ディスク容量、メモリ、および I/O が多くなります。

可能であれば、自動インクリメント整数キーを使用し、ハッシュ識別子列に一意のインデックスを作成することをお勧めします。

于 2012-12-21T20:13:00.500 に答える
1

tmによります;）

説明から判断すると、このフィールドはデータに固有のものであり、一意である必要があります。それが本当に当てはまる場合は、それをキーにする必要があります。子テーブルがある場合は、単に子 FK をスリムに保ち、ON UPDATE CASCADE を回避するために、別の、いわゆる「サロゲート」キーを導入することを検討してください。ただし、特にクラスター化されたテーブルの場合、追加のインデックスごとにオーバーヘッドが発生することに注意してください。サロゲート キーの詳細については、こちらを参照してください。

一方、このキーがデータ モデルに固有のものでない場合は、小さいキー (自動インクリメントされた整数など) に置き換えます。ディスク容量をいくらか節約し、(さらに重要なことに) キャッシュの有効性を高めます。

于 2012-12-21T21:50:05.407 に答える
0

このキーは、いくつかの理由で不適切です。

  • 1つは@Ericによって対処され、すべてのセカンダリインデックスに同じ32文字が含まれます
  • 主キーは他のテーブルからのルックアップとして使用される傾向があり、それらのテーブルにもそれらの 32 文字が必要です。おそらくそこに主キーがあり、それらのテーブルで同じ問題が再び発生します。
  • 私が考えることができる最大の理由はパフォーマンスです。ハッシュタイプのレコードを挿入すると、基本的にランダムな順序でキーを挿入することになり、最終的に多くのページ分割と 50% から 90% の間しか満たされていないページが発生します。これにより、不必要に深いツリーが作成され、検索時間が長くなり、テーブル スペースが大きくなり、インデックスがより多くのメモリを必要とします。
于 2012-12-21T20:42:09.273 に答える
0

主キーの定義方法は、使用方法によって異なります。通常、主キーには INT(11) を使用します。これにより、外部キーが非常に簡単になります。

私はちょうどあなたの編集を見ました。個人的には、自動インクリメントで int(11) を使用します。設定によっては、これにより、外部キー制限のある他のテーブルを非常に簡単に作成できるようになります。varchar でも同じことができますが、特にインデックスの場合、int は varchar よりも高速であることが常に理解されています。

于 2012-12-21T20:12:28.440 に答える
0

これを PKEY として使用しても、本質的に問題はありません。これを FKEY として使用する他の多くのテーブルがある場合は、おそらくそうではありません。誰も答えはありません。

また、常に正確に 32 文字になることがわかっている場合は、代わりに CHAR(32) にする必要があります。

于 2012-12-21T20:13:10.500 に答える
0

データベース エンジンで最も重要な項目の 1 つはディスク容量です。小さくてコンパクトなデータを維持することは、通常、データベースによって送信および転送されるデータの量を減らすことにより、優れたパフォーマンスに関連付けられます。テーブルに数行ある場合、INT 型の PK を定義する理由はありません。代わりに MEDIUMINT、SMALLINT、または TINYINT を使用することもできます (DATETIME の代わりに DATE を使用するのと同じように)。

于 2012-12-21T20:18:42.490 に答える