PostgreSQLのプライマリーキーはSERIALとUUIDのどっちが速いのか実験してみた - Qiita

注意 この記事の実験は実際の運用を正確に反映していない恐れがあります（コメント欄の @hmatsu47 さんの投稿を参照）。 実務のアプリケーションでは異なる結果になる可能性もあるので、本記事の内容はあまり鵜呑みにせず参考程度に留めておいてください。 ※「実務に近い環境で実験してみた」という投稿もお待ちしています！ はじめに データベース（この記事ではPostgreSQLを対象とします）の主キーは1,2,3のような連番の整数値を主キーにするSERIALと、"00009236-b73c-4338-8ebd-e1f6c4f4fdd8"のようなランダムな文字列を主キーにするUUIDがあります。 それぞれメリットとデメリットがありますが、パフォーマンスについてはどうでしょうか？なんとなくSERIALの方がシンプルなぶん、速そうなイメージがありますが、実際はどうなのか調べてみました。 実行環境 Ma

[n314]

uuidって複数のノードから同時に書き込んでも競合しないのがメリットじゃなかったっけ？値をDBで生成するならserialでいいような。

[bootJP]

参照局所性がなくなると思うので、データ量以外にも要因がありそうな気がする

[hate_nao]

ulidも試してほしい

[roshi]

時系列で並べられるSERIALが好み。ULIDがネイティブで使えればそれでもいいけど。

[circled]

DBはカラムサイズが小さければ小さいほど処理が速いのでtextよりはvarchar、varcharも短ければ短いほど速いわけだから、単なる整数のSERIALに対して、長々としたテキストデータのUUIDが勝てる要素は初めから無いのよ。

[taruhachi]

単一のクライアントから並列度1でシーケンシャルに処理するケースと、複数のクライアントから同時に投げられるケースでだいぶん違った結果にはなる。その意味でベンチマークをシーケンシャルにとってはいけない。

[xlc]

RDBとして使うなら業務上識別可能なIDをキーとすべきだし、それがないならNoSQLでよいのだと思ってる。

[sakuro]

UUID型って内部表現も128ビット整数じゃなくUUID文字列なの?

[shag]

とはいえ、明確に UUID として key を使う時しか使わんだろうしな。

[ya--mada]

UUIDv4 の話。

[nmcli]

概ね想像通りの結果に

[asuka0801]

MySQLの場合はクラスタインデックス構造だからUUIDを指定すると分散してしまって遅いという理屈は分かるんだけどPostgreSQLで遅くなる理由は何だろう。もう少し詳細が知りたい。

[kako-jun]

作り直せないPKでなんて残酷な実験を……と思ったけど、SERIALで作ってたので倍嬉しい