[解決済み] MySQLにおけるUUIDのパフォーマンス？

質問

私たちは、MySQLデータベースの主キーとしてUUID値を使用することを検討しています。挿入されるデータは、数十、数百、あるいは数千のリモート コンピューターから生成され、毎秒 100 ～ 40,000 挿入の速度で挿入され、更新は決して行いません。

データベース自体は、通常、データのカリングを開始する前に約 5,000 万レコードに達するので、巨大なデータベースではありませんが、小さいわけでもありません。私たちはまた、InnoDB で実行することを計画していますが、私たちが行っていることに適したエンジンがあれば、それを変更することも可能です。

私たちは、Java のタイプ 4 UUID を使用する準備ができていましたが、テストではいくつかの奇妙な動作が見られました。たとえば、私たちは varchar(36) として保存していますが、binary(16) を使用する方がよいということに気づきました (ただし、どの程度よいかはわかりません)。

より大きな疑問は、50M のレコードがある場合、このランダムなデータがインデックスをどれほど悪化させるかということです。たとえば、左端のビットがタイムスタンプされたタイプ 1 の UUID を使用した方が良いのでしょうか？あるいは、UUIDを完全に捨てて、自動インクリメントの主キーを検討すべきでしょうか？

私は、異なるタイプの UUID が MySQL のインデックス/主キーとして格納される場合のパフォーマンスに関する一般的な考え/ヒントを探しています。ありがとうございます。

どのように解決するのですか？

UUIDとは、Universally Unique IDのことです。ここで考えるべきはUniversallyの部分です。

あなたは 本当に は普遍的に一意である必要があるのでしょうか？もしそうなら、UUID が唯一の選択肢になるかもしれません。

私が強くお勧めするのは、もし する を使用する場合は、文字列としてではなく数値として保存することを強くお勧めします。50M 以上のレコードがある場合、ストレージ スペースを節約することでパフォーマンスが向上します (どの程度かは言えませんが)。

ID が普遍的に一意である必要がない場合、テーブル内で ID が一意であることを保証する auto_increment を使用するより良い方法はないと思います (値は毎回増加するため)。