データベースアクセスの高速化

順番に意味はない

そもそもアクセスしない。

一度アクセスした結果をキャッシュで持つ。

インデックスを使うようにする。

テーブルのシーケンシャルアクセスにならないようにする。

インデックスを付けすぎないようにする。

インデックスを増やすとインデックステーブルへの追加・削除のコストが上がる。

SQLの発行回数を減らす。

プリペアドステートメントを使って、SQL文の解析を減らす。

不要な項目をSELECTしない。

頻繁にアクセスされる列とそうでない列に分けてテーブルを分割する。

レコードを1ページ(1セクタ)の中に多数入れるようにする。

頻繁にアクセスされないレコードを分離する。

過去データを別のテーブルに追い出すなど

転送されるデータ量を減らす。

高速なストレージを使う。

SQL で処理するのをやめ、メモリ上に読み出して、その中で処理をする。

分散データベース(レプリカなど)にして、処理を分散させる。

どの部分のパフォーマンスを上げようとしているのかを理解する。

必ずしもブロックごとに実行順が分かれているわけではなくて、ストリーム的に連続して実行されていることがある。

SQL文の組み立て

変数から入力パラメータへデータ転送

SQL文と入力パラメータの送信

SQL文の解析

ストレージへのアクセス(読み出し/書き込み)

集合演算

結果レコードセットの組み立て

結果レコードセットの送信

結果レコードセットから実際に使う変数などへのデータ転送

既知の問題

原因

IDがすべてのページに分散されてしまう。そのすべてのページをメモリ上に載せきれないため、ストレージから毎回取り出すようになってしまう。(キャッシュのヒット率が十分高いとかアクセス頻度が低いなら問題にならない。)

対策

メモリを十分に用意して、キャッシュからすぐには破棄されないようにする。

参考

MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと

関連