Relational Database
Overview
リレーショナルデータベースに関する情報をまとめたセクション。
特徴としてはデータを人間が管理しやすい2次元表の形式で管理する。
長い歴史を持つ
誕生は1969年まで遡る。
すでに登場してからデータベースのメインストリームの座になる。
DBセッションの切り方
- mysql
- DBクライアントの接続を切ってもセッションは切れない(SQLは実行されたまま)
- そのためオーバーフローしやすい
- postgres
- DBクライアントの接続を切った場合セッションは切れる(実行されいるSQLがあれば終了する)
リソースの解放
クエリが中止されると、そのクエリによって使用されていたリソース(メモリ、一時的なディスクスペースなど)も解放されることが一般的。
これにより、システムのリソースがムダに消費されることを防ぐ。
ロールバック: トランザクション内で実行されていたクエリの場合、未完了のトランザクションは自動的にロールバックされることが多いです。これにより、データベースの整合性が保たれる。
長時間クエリの実行対策
パフォーマンスチューニングは必須だが、まずはタイムアウトを設定しておく。
フルテーブルスキャンはしない
SELECT文であるレコードを取得したいときに、対象のテーブルを全件検索してしまっている検索方法
LIKE *
などをするとフルテーブルスキャンをしてしまうため注意が必要!
フルテーブルスキャンをしてしまう構文
MySQLだとSELECT Queryの前に EXPLAIN
をつけることで確認ができる。
typeの判別
type | 検索方法 |
---|---|
ALL | フルスキャン、全件検索 |
index | フルインデックススキャン |
const | 主キーやユニークキーを使って検索 |
eq_ref | ↑と類似。表結合しているものに使われると表示される |
ref | ユニークじゃないインデックスを使って検索 |
range | インデックスを使って検索 |
問題なのが前述の「ALL」と「index」
インデックスを作るときの基準
データ量の多いテーブルにだけ作成する。 なぜなら、データ量の少ないテーブルの場合フルスキャンの方が処理が速いため つまり、インデックスを利用して取得する方が遅くなってしまう。 MySQLのドキュメントにもこのように記載がある。
インデックスが作成される条件
-
プライマリキー
- プライマリーキーに対して自動的にインデックスが作成される。プライマリーキーはテーブル内の各行を一意に識別するために使用され、データベースはこのキーを効率的に検索できるようにインデックスを利用します。
-
ユニークキー
- ユニークキー(UNIQUE KEY)にも自動的にインデックスが作成される。ユニークキーはデータベース内のテーブルで、指定されたカラムの値がテーブル全体で一意であることを保証するため一意性を効率的に保証するために、データベース管理システムはユニークキーに対して自動的にインデックスを作成する。