質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
SQL

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

Q&A

解決済

4回答

6370閲覧

データベースのパフォーマンスで疑うべき3つのポイント

ayu

総合スコア212

SQL

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

0グッド

3クリップ

投稿2017/06/04 13:14

こんばんわ。

データベースのパフォーマンスについて、質問したいことがあります。

  • データベースのパフォーマンスが悪い理由
  • n + 1問題
  • index問題

この3つ以外にあると思うので、もしあればなぜ、それを見直すべき必要があるのかの理由も書いてほしいです。

自分の理由です。

データベースのパフォーマンスが悪い理由

コンピュータはメモリー上のデータの出し入れは早いが、HDDへのアクセスは遅い
データベースはHDDへのアクセスを行っているので、基本的にパフォーマンスは遅くなる。
もし、メモリー上にデータベースを展開できるのなら、高速アクセスは可能になる
→redis, memcached
Mysqlもクエリをメモリー上にキャッシュをするが、全てできるわけではない

n + 1問題

ループで回す処理を毎回クエリを作成しているので遅くなる。
クエリを工夫するだけで一回で取得できる。
このことから、n + 1問題に限らず、余計なクエリを作成しているところを直すことが必要。

index問題

HDDにアクセスする際に、indexがないとレコード全てから探すことになる。
indexを貼ってあれば、余計なレコードから探さなくて良くなる

まとめ

  • データベースのパフォーマンスが悪い理由

→コンピュータの性質の問題

  • n + 1問題

→クエリの問題

  • index問題

→DBアクセスの検索ロジックの問題

まとめると上記の中身だと思っています。
これ以外に注意点や、考えが間違っていることがあれば、教えていただきたいです。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Zuishin

2017/06/04 13:21

質問をもう一度読み直してみてください。
ayu

2017/06/05 12:19

あまり質問になっていなかったですね。申し訳ございませんでした。
guest

回答4

0

ベストアンサー

クエリの実行計画も重要な問題となります。とりわけ、複数のテーブルを組み合わせるような複雑なSQLを組み立てる場合、SQLの実行エンジンが不適切な実行法を選択してしまえば、無駄に時間がかかってしまいます。

幸い、実行計画を調べる方法もありますので、遅いクエリに対しては確認を行ってみましょう。

MySQLのEXPLAINを徹底解説!!

投稿2017/06/04 13:25

maisumakun

総合スコア145121

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

ayu

2017/06/05 12:27

確かに・・・。 EXPLAINで原因を調べるのは、基本ですね。 基本が抜けてましたm(_ _)m ありがとうございます!
guest

0

システム規模やテーブル数、レコード数など、
いろいろな要因があるので、
「パフォーマンスに悪影響も及ぼすのは、これ」という回答はありません。

質問で言われている3つのポイントで、
間違っていることはありませんが、問題を解決してもパフォーマンスが必ず向上するわけではありません。

例えば、
一番多いレコードが5万レコードを下回るようなテーブルしかない小規模のシステムであれば、
おそらくどれも問題になりません。
(少々の速度向上には繋がるかもしれませんが、有意義なものではないと判断されることのほうが多い)

投稿2017/06/05 02:51

szk.

総合スコア1400

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

ayu

2017/06/05 12:24

>一番多いレコードが5万レコードを下回るようなテーブルしかない小規模のシステムであれば、 おそらくどれも問題になりません。 なんと! それ以上じゃないと、そこまで効果ないんですね。 無意味にでかいサイトをイメージして頑張ります。
guest

0

場合によってはインデックスを使わずフルスキャンしたほうが早い場合さえあります。
インデックススキャンするということは、インデックスによってレコードを決定できる、ということでしかありません。
その後にレコードを読むことになった場合、シーケンシャルに一気に読めるフルスキャンより、ランダムアクセスになって遅くなる可能性があるのです。
※インデックスによる絞り込みが十分ではなく、また SELECT 対象がインデックスの構成要素以外にもある場合が該当する

投稿2017/06/05 03:03

tacsheaven

総合スコア13703

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

ayu

2017/06/05 12:20

インデックスが常に最適なわけではないのですね。 > SELECT 対象がインデックスの構成要素以外にもある場合が該当する なるほど! ありがとうございます!
guest

0

MySQLで言うと、相関サブクエリが劇的に遅いというのが有名ですね。
相関サブクエリとは、サブクエリ内で外部のクエリ結果を参照しているものです。
ようは、サブクエリ単体では実行できないやつですね。(他に依存しているため)
ちょっといい例が浮かばいのですが、例えば以下のようなやつです。

SQL

1SELECT 2 * 3FROM 4 FOO A 5WHERE 6 A.CODE IN ( 7 SELECT 8 B.CODE 9 FROM 10 BAR B 11 WHERE 12 A.CODE = B.CODE /* ここでAを参照している */ 13 );

これは以下のように書き換えれば問題なくなります。

SQL

1SELECT 2 * 3FROM 4 FOO A 5 INNER JOIN BAR B 6 ON A.CODE = B.CODE;

相関サブクエリは実行計画では、DEPENDENT SUBQUERYとなるので、
そこは確実にチューニングポイントになります。

ただし、MySQL5.6からはオプティマイザが賢くなっているようで、
相関サブクエリでも、DEPENDENT SUBQUERYにはならないようになっているようです。
つまり速くなったということです。

投稿2017/06/05 01:01

編集2017/06/05 01:02
root_jp

総合スコア4666

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

root_jp

2017/06/05 01:05

すみません。すでに書かれている >余計なクエリを作成しているところを直すことが必要。 に該当しますね。流してください。
ayu

2017/06/05 12:26

相関サブクエリについて、丁寧な解説ありがとうございます! 仕組みが分かっていなかったので、大変助かりましたm(_ _)m ありがとうございます!
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問