web-dev-qa-db-ja.com

UserIDに最適な識別子は何ですか？ 64ビット整数、UUID V5、または64文字のSHA256 UID？

アプリケーションの将来性を保証します。使用するのに最適な識別子のタイプは何ですか？

私は検討しています：

  1. 64ビット整数
  2. UUID
  3. 64文字のSHA256

分散システムを開発していないので、UUIDを使用する必要がありますか？

また、INTEGER結合とVARCHAR結合はどの程度優れていますか？

最後に、ユーザー名（一意）とメッセージデータを同じMySQLテーブルに格納する方が、ユーザーIDを格納するよりも優れていますか？

mysqldatabase-designdatatypes
5
user1203914

整数を使用します。これが最も簡単で効率的な方法です（特にInnoDBの場合）。

あれは

  • intの代わりにハッシュ、UUID、またはvarcharを使用しないでください
  • 外部キーがある場合は、自然キーを使用しないでください

理由は？

  • varcharの比較には照合+ケーステストが必要
  • innoDBのインデックスアーキテクチャは整数フィールドを優先します（理想的なクラスター化インデックスは狭く、数値で、単調増加します）
  • ハッシュとGUIDおよびvarcharは断片化を引き起こす
  • より広いデータ+整数を使用しない場合の行のインデックス付け
  • 64文字を格納するには64/66バイトが必要です。 64ビット入力には8バイトが必要

その他の観察：

  • 64ビットの数値が必要ですか？
7
gbn

UUID/GUIDは、グローバルに一意のIDを作成する複数の独立したコンピューターが必要な場合に適しています。

しかし、主キーとして吸う。

それらは大きいです-36文字ですが、デフォルトでutf8にすると、やりすぎです。それらの16進数はBINARY（16）に変換できます。 InnoDBでは、すべてのセカンダリキーにPKが追加されるため、かさばるPKのスペースコストが倍増します。

それらはランダムです-キャッシュできるよりも多くのデータを取得すると、通常はフェッチごとにディスクにアクセスします。これにより、パフォーマンスが最大100オペレーション/秒に低下します。スケーラビリティが必要なときだけ、それはあなたから取り除かれます！

すべての書き込みが単一のマスターに対して行われる場合は、AUTO_INCREMENTを使用します。MEDIUMINTUNSIGNEDは最大16M、INT UNSIGNEDは最大4G、または非常に楽観的な場合はBIGINT。

VARCHAR、BINARY、INTなどのCPUパフォーマンスについては、それは問題ではありません。問題はキーの大きさです。これはINDEXのキャッシュ可能性につながり、I/Oがボトルネックになるためです。すべてをキャッシュできる場合は、キーのタイプとサイズを気にする必要はありません。 （OK、JOINのデータ型は同じであるか、十分に近い必要があります。たとえば、照合順序が異なると、インデックスの使いやすさが損なわれます。）

2
Rick James