3

MySQLデータベースのいくつかのテーブルの主キーとしてクライアント提供のUUIDを使用することを計画しています。

UUIDをMySQLデータベースに格納するためのさまざまなメカニズムに出くわしましたが、それらを相互に比較するものはありません。これらには、次のようなストレージが含まれます。

  • BINARY（16）
  • CHAR（16）
  • CHAR（36）
  • VARCHAR（36）
  • 2 x BIGINT

より良いオプションはありますか、オプションは次の点で互いにどのように比較されますか？

  • ストレージサイズ？
  • クエリのオーバーヘッド？（インデックスの問題、結合など）
  • クライアントコードからの値の挿入と更新のしやすさ？（通常、JPA経由のJava）

実行しているMySQLのバージョン、またはストレージエンジンに基づく違いはありますか？現在5.1を実行しており、InnoDBの使用を計画していました。UUIDを使用しようとした実際の経験に基づいたコメントを歓迎します。ありがとう。

4

2 に答える 2

3

実際にUUIDを使用するように設定されている場合は、Binary（16）列に格納することにします。2x bigintのようなものは、管理が非常に面倒です。また、同じマシン上のUUIDの開始は最初は同じで、最後は異なる部分であるため、それらを逆にする人の話を聞いたことがあります。したがって、それらを逆にすると、インデックスがより効率的になります。 。

もちろん、私の本能では、UUIDを使用する本当に正当な理由がない限り、自動インクリメント整数を使用する必要があると言っています。理由の1つは、さまざまなデータベース間で一意のキーを生成することです。もう1つのオプションは、INTが格納できるよりも多くのレコードを計画することです。多くのアプリケーションが実際にこのようなものを必要としているわけではありませんが。キーに整数を使用しないと、効率が大幅に低下するだけでなく、キーを操作するのも難しくなります。それらは長すぎて入力できず、URLに渡すと、URLが非常に長くなります。したがって、必要に応じてUUIDを使用しますが、近づかないようにしてください。

于 2009-09-01T16:38:14.440 に答える
1

スマートクライアントのオンライン/オフラインストレージとデータ同期、およびある時点でマージする必要があることがわかっているデータベースにUUIDを使用しました。私はいつもchar（36）またはchar（32）（ダッシュなし）を使用してきました。varcharよりもパフォーマンスがわずかに向上し、ほとんどすべてのデータベースがcharをサポートしています。私はbinaryやbigintを試したことがありません。注意すべきことの1つは、36文字または32文字を使用しない場合、charはスペースで埋められるということです。つまり、オブジェクトのIDを「テスト」に設定してデータベースで検索しようとする単体テストを作成しないでください。;）

于 2009-09-01T16:54:13.830 に答える