DBは主キーの形式(?)で速さが変わるらしいから検証してみた

はじめに

こんにちは。普段はWebアプリの開発を行っている者です。
投稿は初めてなので、お手柔らかに...

タイトルの通りですが、今回は以下の記事を見て主キーの形式(言い方があっているかわかりませんが、uuidにするとかランダムな文字列にするとか)によって処理速度に違いが出るらしいので、検証してみました。

経緯

今まで特に大規模な開発に携わったこともなく、速さなんて気にしたことがなかったので「一意に決まれば何でもいいっしょ」って思いながら主キーを決めていました。そんなある日、以下の記事を読んで衝撃を受けたので、自分でも検証をしてみました。

やってみる

とにもかくにも動かしてみよう！ということで、実験してみます！
今回は普段私がよく使っているMySQLで試します。

方法

以下の手順をidの形式ごとに行います。

1. insertを10万回実行
2. 1で挿入したレコードに対してselectを10万回実行

エントリーNo.1 uuidv4

まずはuuidv4です。説明するまでもないですね
結果は以下のようになりました。単位はmsで、それぞれの値は平均値です。

insert	select
0.450	48.041

エントリーNo.2 uuidv7

v4をやったので、v7もやってみました。
結果は以下の通りです。

insert	select
0.398	54.802

エントリーNo.3 ランダムな文字列

普段私が使用している方法です。アルゴリズムはシンプルで、アルファベット大文字と0～9までの数字をランダムに255桁並べただけです。とりあえず一意の文字列を生成させたくて脳死で作ったアルゴリズムを今でも使ってます笑

insert	select
0.429	51.542

エントリーNo.4 通し番号

単純に0～100,000までの番号をidにします。
結果は以下の通りです。

insert	select
0.411	54.225

結果

上の記録をまとめてみました。

形式	insert	select
uuidv4	0.450	48.041
uuidv7	0.398	54.802
ランダム	0.429	51.542
通し番号	0.411	54.225

insertが速い順だと

1. uuidv7
2. 通し番号
3. ランダムな文字列
4. uuidv4

selectが速い順だと

1. uuidv4
2. ランダムな文字列
3. 通し番号
4. uuidv7

となりました！
insertが速いほど、selectは遅くなることにはびっくりです。記事を書く前に「insertもselectもこれが速いからみんな使おうね！」みたいにまとめるつもりが、予期せぬ事態となりました...

終わりに

私はDBに関しては必要最低限の知識しかないので、なぜこうなるかは分かっていませんが、何か意味ありげな結果になったので、また今度調べてみたいと思います！

最後までご覧いただき、ありがとうございました。少しでも有益な情報になっていれば幸いです！
ではまた。