書籍タイトル：おうちで学べるデータベースのきほん 第2版
読む時間：07:03
はじめに
先月から新しい案件に配属され、バックエンドの設計・開発を一人で担当することになりました！
CMSツールを活用しながら、データベースやAPIなど、さまざまなバックエンド機能を構築していくのですが、
初期のテーブル設計がしっかりしていないと、後々の機能設計に大きな影響を与えると思い、
できるだけ適切なデータベース設計を行いたいと考えています。
そのため、データベースの基礎から復習しようと思い、本書を購入しました。
📚 本書の詳細情報
印象に残ったポイント
1. インデックスと主キー（PK）を混同しないように
主キー（PK）は、各レコードに対して一意となるIDであり、多くの場合、レコード挿入時に自動でUUIDが付与される設計になっています。
このように、主キーはレコードごとに「ユニーク」な値となるため、検索時にもよく使われます。まるで書籍の目次のような役割を果たすため、
「主キー＝インデックス」と誤解されがちですが、正確には異なります。
確かに、主キーの列には自動的にインデックスが作成されますが、主キー以外の列にもインデックスを設定することは可能です。
つまり、「インデックス＝主キー」ではなく、「主キーにはインデックスが張られるが、インデックスは主キーに限らない」という関係です。
2. 勝手にインデクスを増やさないように
主キー以外の列にもインデックスを設定することができます。
たとえば、Userテーブルの「名前」列にインデックスを設定すると、「名前」で WHERE 条件を使った検索がより効率的になります。
ただし、「じゃあ、すべての列にインデックスを付ければ検索が爆速になるのでは？」と考えて、全列にインデックスを張るのは新人の方がやりがちな落とし穴です。
これは避けてください。
確かに検索速度は向上する可能性がありますが、インデックスが増えると、データの「更新」時や「バックアップ」時にインデックスのメンテナンス処理が増えるため、
パフォーマンスの低下やストレージの無駄遣いにつながります。つまり、インデックスは便利な一方でトレードオフがあるという点を理解しておく必要があります。
3. SQLの実行計画を理解しよう
SQLを実行すると、DBサーバーのオプティマイザーが自動的に最適な方法でデータを取得してくれるイメージがありますが、
その裏側でサーバーがどのような処理をしているのかを気にする人はあまり多くないように感じます。
実際には、サーバーはテーブルのさまざまな「統計情報」をもとに、データアクセスの最適な計画（実行計画）を立てています。
イメージとしては、気象情報をもとに登山ルートを決めるようなものです。
以下のSQLを使えば、そのような統計情報や、インデックスが利用されているかどうかなど、オプティマイザーの判断内容を確認することができます。
show table status
explain select * from table_name
まとめ・感想
本書は、データベースの歴史や基礎知識を丁寧に解説しており、初心者向けのテキストという印象を受けました。
エンジニア5年目にもなって「初心者向け？」と思われるかもしれませんが、これまでの業務では、私は常に“データベースを使う側”であり、“設計する側”ではありませんでした。
そのため、細かい部分まで意識することなく、データベースの恩恵を受けてきたのが正直なところです。
これまでWeb系の開発では、あまり深く考えずにAPI経由でデータをfetchし、その裏でサーバーがどのようにSQLを発行しているのか、またSQLがどのように解析され、どうやってデータを取得しているのかを意識していませんでした。
しかし、今はテーブルを設計する立場になったため、業務でどのようにデータを扱いたいのかを考慮しながら、
適切にSQLを設計し、必要なインデックスの設計も行っていきたいと思っています。
今回本書を読んだことで、あらためてデータベースの基礎を体系的に復習でき、
Webエンジニアがつい見落としがちなポイントも再確認できて、とても有意義な内容でした。