主キー設計では、「自然キー vs サロゲートキー」や「連番 vs 乱数」が主題になることが多いですが、今回はカラムサイズに注目して、主キーのサイズが検索性能に与える影響について調査してみたいと思います。
インデックスを使った検索が高速であることはRDBの常識中の常識ですが、その時もディスクやメモリからインデックスの値を読み取ってCPUを使って比較を行う操作が発生するわけで、値のサイズが小さいことは理屈上ではCPUキャッシュの利用やその他IO処理などにおいて有利に働くはずです。
今回は主キーを指定した単体取得のクエリにおいて、その影響がどの程度なのかを実際に計測して確認してみたいと思います。
[...]文字列型同士の比較では主キーのサイズと検索速度にきれいな相関が見られますが、異なる型の間では主キーサイズは検索速度の大きな決定要因にはならないようです。
特に int_table の検索が想像よりもずっと遅く、long_table よりも int_str_table よりも遅くなっています。 int_str_table の結果は主キーのサイズがより小さい long_table の結果よりも早いので、文字列比較が早くなる原因 (or 数値比較が遅くなる原因) が何かしら存在していそうです。
ただ、UUIDに限って言えば、「UUIDを文字列型で保存すると速度的に不利」という言説は、顕著な違いが確認できました。
「主キーのカラムサイズが大きいほど検索性能が下がる」という常識的な仮説は、実際に計測してみたら、異なる型の間では成立しませんでした。
「推測するな、計測せよ」という格言の大切さを実感させられます。
ただ、クエリの実行速度はRDBMSの実装だけではなくCPUアーキテクチャなどにも依存しているはずなので、クラウドサービス上などの別の環境で計測したら別の結果が出るかもしれません。
例えば、1つの比較実験として同じ環境で shared_buffer のサイズを最小値の128kBまで下げた状態でも計測を実行してみましたが、テーブルごとの傾向も実際の計測時間も大きな変化は見られませんでした。