UUIDのベストプラクティス

UUIDの概要

AUTO_INCREMENT整数値の代わりに主キーとして使用される場合、ユニバーサル一意識別子 (UUID) には次の利点があります。

UUID は、競合の危険を冒さずに複数のシステム上で生成できます。場合によっては、これは、TiDB へのネットワークトリップの回数が削減され、パフォーマンスの向上につながることを意味します。
UUID は、ほとんどのプログラミング言語とデータベースシステムでサポートされています。
URL の一部として使用される場合、UUID は列挙型攻撃に対して脆弱ではありません。これに対し、数字がauto_increment場合は、請求書 ID またはユーザー ID を推測することができます。

ベストプラクティス

バイナリとして保存

テキストの UUID 形式は次のようになります: ab06f63e-8fe7-11ec-a514-5405db7aad56 、これは 36 文字の文字列です。 UUID_TO_BIN()を使用すると、テキスト形式を 16 バイトのバイナリ形式に変換できます。これにより、テキストをBINARY(16)列に保存できます。 UUID を取得する場合、 BIN_TO_UUID()関数を使用してテキスト形式に戻すことができます。

UUID形式のバイナリ順序とクラスタ化されたPK

UUID_TO_BIN()関数は、1 つの引数 (UUID) または 2 つの引数 (2 番目の引数がswap_flagとともに使用できます。

ホットスポットを避けるために、TiDB ではswap_flagを設定しないことをお勧めします。

ホットスポットを回避するために、UUID ベースの主キーに明示的にCLUSTEREDオプションを設定することもできます。

swap_flagの効果を示すために、同じ構造を持つ 2 つのテーブルを示します。違いは、 uuid_demo_1に挿入されたデータはUUID_TO_BIN(?, 0)を使用し、 uuid_demo_2挿入されたデータはUUID_TO_BIN(?, 1)を使用することです。

以下のキービジュアライザーのスクリーンショットでは、バイナリ形式でフィールドの順序が交換されたuuid_demo_2テーブルの 1 つの領域に書き込みが集中していることがわかります。

Key Visualizer

CREATE TABLE `uuid_demo_1` (
  `uuid` varbinary(16) NOT NULL,
  `c1` varchar(255) NOT NULL,
  PRIMARY KEY (`uuid`) CLUSTERED
)

CREATE TABLE `uuid_demo_2` (
  `uuid` varbinary(16) NOT NULL,
  `c1` varchar(255) NOT NULL,
  PRIMARY KEY (`uuid`) CLUSTERED
)

MySQLの互換性

UUID は MySQL でも使用できます。 BIN_TO_UUID()とUUID_TO_BIN()関数はMySQL 8.0 で導入されました。 UUID()関数は、以前の MySQL バージョンでも使用できます。