やあ。最近、データベースの設計レビューをしていて少し気になったことがあるんだ。
PostgreSQLを触っていると当たり前のように使う「boolean型」。これ、ただの「フラグ」だと思って軽視してないかな？実は、この小さな型一つとっても、設計の良し悪しでパフォーマンスや運用のストレスが劇的に変わるんだ。
今日は、現場でハマりやすいboolean型の落とし穴と、プロとして知っておくべきインデックス戦略について話そうと思う。
—
boolean型は「3値」であるという事実
まず、基本の確認だ。PostgreSQLのboolean型は、`true` と `false` だけじゃない。`null` を含めた「3値論理」なんだよね。
これ、初学者が一番ハマるポイントなんだけど、SQLの `WHERE` 句で条件を書くときに油断すると痛い目を見る。
— よくあるミス
SELECT FROM users WHERE is_active = false;
もし `is_active` が `null` のデータがあったら、このクエリでは一切拾われない。`IS NULL` を明示的に指定しない限り、null値は「存在しないもの」として扱われるからだ。
「とりあえずフラグだから `NOT NULL DEFAULT false` をつけておくか」という設計は、実はかなり合理的だ。特別な理由がない限り、booleanカラムには制約をかけておくことを強く勧めるよ。
インデックスが効かない？「カーディナリティ」の罠
さて、ここからが本題だ。データベースエンジニアとして一番気になるのは「インデックスをどう貼るか」だよね。
多くのエンジニアがやりがちなのが、これだ。
CREATE INDEX idx_users_is_active ON users (is_active);
結論から言うと、boolean型単体へのインデックスは、ほとんどの場合で無駄だ。
なぜか？それは「選択率（カーディナリティ）」が低すぎるからだ。データベースのオプティマイザは、インデックスを使ってデータを検索するよりも、テーブル全体をスキャン（シーケンシャルスキャン）したほうが早いと判断することが多い。特にデータ件数が少ないうちはいいけど、数百万件を超えた瞬間にインデックスが使われないという「悲劇」が起きる。
じゃあ、どうやって高速化するのか？
もし「アクティブなユーザーだけ取得したい」というクエリが頻発するなら、インデックスの貼り方に工夫が必要だ。
1. 部分インデックス（Partial Index）を使う
これが一番の特効薬だね。
CREATE INDEX idx_users_is_active_true ON users (id) WHERE is_active = true;
これなら、インデックスのサイズは非常に小さく保たれるし、検索効率も爆上がりする。必要なデータだけをピンポイントでインデックス化する。これがPostgreSQLの真骨頂だよ。
2. 複合インデックスで「ついでに」検索する
もし他の条件と一緒に絞り込むことが多いなら、複合インデックスの一部に組み込むのも手だ。
CREATE INDEX idx_users_status_created ON users (status, created_at);
この場合、`is_active` ではなく、より絞り込み条件として強いカラムを先に持ってくる。boolean型は「絞り込みの補助」として使うのが、インデックス設計の定石さ。
最後に：booleanを使うべきか、使わざるべきか
たまに「将来的に状態が増えるかもしれないから、booleanじゃなくて integer 型や enum にしておこう」という設計を見かける。
これについては、僕はこうアドバイスしているよ。
「今、そのデータが二択なら、迷わず boolean を選べ」と。
後から列挙型に変更するのは `ALTER TABLE` で難しくないし、何よりコード上で `if (user.is_active)` と書ける可読性は、開発スピードに直結する。オーバーエンジニアリングで最初から複雑な型にする必要はないんだ。
—
データベース設計は「今」の要件と「未来」のパフォーマンスのバランスを取るゲームのようなもの。boolean一つとっても、その扱い方にはエンジニアの経験が出る。
もし君のプロジェクトで「この検索、なんだか遅いな？」と感じたら、まずは `EXPLAIN ANALYZE` を叩いてみてほしい。インデックスが本当に使われているか、無駄なスキャンをしていないか。そこから全てが始まるから。
また何か気になったら聞いてくれ。現場からは以上だ！
コメント