「テーブルの列の順番なんて、どれも同じじゃないの？」
もしあなたが今、そう思っていたとしたら……ちょっと待ってください！実はそれ、「知っているだけでストレージ代が浮く（そしてパフォーマンスも上がる）」という、データベース設計のちょっとした裏ワザなんです。
今日は、プロの現場でも意外と見落とされがちな「パディング」という現象について、日常の例え話を交えながら楽しくお話ししますね。
—
荷造り上手は、パズルも上手？
想像してみてください。あなたは今、大きなスーツケースに荷物を詰めようとしています。
ここには「とても大きなテディベア」と「小さな靴下」があるとします。もし最初に小さな靴下をポイっと放り込んで、その次にテディベアを詰めようとすると、どうなるでしょう？
靴下のせいで、テディベアがうまく奥まで入らず、隙間ができちゃいますよね。その隙間は、結局「何も入れられない死に体」になってしまいます。
実は、PostgreSQLのテーブルもこれと同じことをしています。これを専門用語で「パディング（詰め物）」と呼びます。
なぜ「隙間」が生まれるのか
PostgreSQLは、データをメモリやディスクに書き込むとき、効率よく読み出すために「データには特定の区切りが必要」というルールを持っています。
例えば、「8バイトの箱には、8バイトのデータしか入れちゃダメ（半分だけ使うのもナシ）」というような、ちょっと厳格なルールがあるんです。
もし、あなたがこんなテーブルを作ったとしましょう。
1. 整数型（4バイト）
2. 文字型（1バイト）
3. 整数型（4バイト）
これ、何が起きるか分かりますか？
PostgreSQLは、2番目の「文字型」を入れたあと、次の「整数型」を入れるために、わざわざ3バイト分の無駄な隙間（パディング）を作ってしまうんです。
「たった3バイト？」と思うかもしれませんが、これが数千万行、数億行と重なると……データベースのサイズは無駄に膨れ上がり、ディスクを圧迫し、読み込み速度もじわじわと遅くなっていくんです。塵も積もれば山となる、ですね。
解決策はシンプル：「大きい順に並べる」だけ！
じゃあ、どうすればいいのか。答えはとってもシンプルです。
「大きいサイズのデータから先に並べる」、これだけです。
先ほどの例を整理してみましょう。
1. 整数型（4バイト）
2. 整数型（4バイト）
3. 文字型（1バイト）
こう並べると、隙間は最小限で済みます。
まるで、大きな荷物を先に詰めて、隙間に小さな靴下を詰め込むようなもの。これなら、スーツケース（テーブル）の中身はスカスカにならず、無駄なくパンパンに詰め込めますよね。
まとめ：明日からの設計に「ちょっとした工夫」を
もちろん、すべてのテーブルでこれを厳密にやる必要はありません。でも、以下のポイントだけ覚えておくと、あなたの設計は一気に「プロの仕上がり」になりますよ。
- データサイズが大きい順に列を並べてみる（8バイトの整数や日付型を先に、1バイトのフラグなどを後に）。
- 「パディング」という概念があることを覚えておく（これだけで、トラブルシューティングの幅がグッと広がります！）。
データベース設計って、実はこういう「整理整頓」の積み重ねなんです。綺麗に整頓されたデータ構造は、コンピュータにとっても読みやすく、結果として私たちのアプリケーションを爆速にしてくれます。
ぜひ次のテーブル作成のとき、「荷造り上手」になったつもりで、列の順番を少しだけ意識してみてくださいね。きっと、素敵なデータベースが出来上がるはずですよ！
それでは、また次回の記事でお会いしましょう！
コメント