MySQL JOINするタイミングによるCPU負荷の違いについて

Question

以下のクエリでは、どちらがCPU負荷が低いでしょうか？

実行時間の改善のため、①から②にクエリを変更したのですが、
DBサーバのCPU負荷がBにしてから上がったように感じました。
こちら、Bの方が負荷がかかるものであるのか、
また、負荷がかかってしまうのであれば何故負荷がかかるのか、
ご教示頂けませんでしょうか？

【①のクエリ(改修前)】
[レコード件数取得]
SELECT COUNT(a.id) FROM A AS a
INNER JOIN B AS b ON a.b_id = b.id
INNER JOIN C AS c ON a.c_id = c.id
WHERE a.b_id = X
AND a.c_id = Y
AND a.name LIKE '%??%'

[レコード取得]
SELECT a.*, b.name, c.name FROM A AS a
INNER JOIN B AS b ON a.b_id = b.id
INNER JOIN C AS c ON a.c_id = c.id
WHERE a.b_id = X
AND a.c_id = Y
AND a.name LIKE '%??%'
ORDER BY a.id　LIMIT 10

【②のクエリ(改修後)】
[レコード件数取得]
SELECT COUNT(a.id) FROM
(
    SELECT id FROM A AS child
    WHERE child.b_id = X
    AND child.c_id = Y
    AND child.name LIKE '%??%'
) AS a
INNER JOIN B AS b ON a.b_id = b.id
INNER JOIN C AS c ON a.c_id = c.id

[レコード取得]
SELECT a.*, b.name, c.name FROM
(
    SELECT * FROM A AS child
    WHERE child.b_id = X
    AND child.c_id = Y
    AND child.name LIKE '%??%'
) AS a
INNER JOIN B AS b ON a.b_id = b.id
INNER JOIN C AS c ON a.c_id = c.id
ORDER BY a.id　LIMIT 10

※Aのテーブルは20万件程
※B、Cのテーブルはそれぞれ100件程

Answer 1

ご推察のとおり、基本的にはBのほうが負荷がかかるクエリです。
# ぜひ、他の方のアドバイスのとおり、EXPLAINを使って実際に見てみていただきたいですが、先に解説してしまいます。

変更前のクエリ

SELECT a.*, b.name, c.name FROM A AS a
INNER JOIN B AS b ON a.b_id = b.id
INNER JOIN C AS c ON a.c_id = c.id
WHERE a.b_id = X
AND a.c_id = Y
AND a.name LIKE '%??%'
ORDER BY a.id　LIMIT 10

（適切なINDEXがはられている前提であれば）
・AテーブルとBテーブルのJOIN
・BテーブルとCテーブルのJOIN
・各種WHERE句（ただし部分一致検索なLIKE検索除く）
・ORDER BY
でINDEXが使われているので、早いと思います。

変更後のクエリ

SELECT a.*, b.name, c.name FROM
(
    SELECT * FROM A AS child
    WHERE child.b_id = X
    AND child.c_id = Y
    AND child.name LIKE '%??%'
) AS a
INNER JOIN B AS b ON a.b_id = b.id
INNER JOIN C AS c ON a.c_id = c.id
ORDER BY a.id　LIMIT 10

テーブルAのところがサブクエリになっているので
テーブルAの検索結果（a）とテーブルbのJOIN、および、テーブルAの検索結果（a）とテーブルcのJOINにINDEXが使用できません。
サブクエリの結果レコード数にもよりますが、20万件→1万件、程度であれば
1万件のデータと100件のデータをINDEX無しでJOINし、さらにその結果に対して100件のデータをINDEX無しでJOINすることになりますので、重いと思います。

ただ、サブクエリの結果がとても少ない場合は（100件等）、変更後のSQLのほうが負荷がかからないかもしれません。

Comments

[WanijimaAgito]

ご回答有難う御座います、申し訳御座いません、ベストアンサー選択後、ご回答を拝見してしまいました。
ご回答いただいた内容を参考に進めさせて頂きます、有難う御座います。

Answer 2

LIKEを使った前方後方一致「%xxx%」絞込はインデックスがききませんので
さきに処理をすると不利になるかもしれませんね
同列で処理をさせるとオプティマイザが他を優先して絞込をしてくれるのかもしれません。
いずれにしても前方後方一致をしている時点でチューニングは限界があると思います

Comments

[WanijimaAgito]

ご回答有難う御座います、オプティマイザについて調べてみます、有難う御座います。

Answer 3

チューニングに関しては、実行計画を確認するのが何よりです。
こちら（MySQLのEXPLAINを徹底解説!!）などを参考にされては如何でしょうか。

但し、上記からの引用ですが、

EXPLAINコマンドはクエリの実行計画を知るためのツールである。どのようにクエリを書き換えれば良いか？というのはまた別の問題であり、EXPLAINコマンドはどのようにクエリを書き換えればいいかについては何も教えてくれない。しかし、ただ一つ言えることはクエリにおいてテーブルからフェッチされる行数を減らすことが重要だと言うことである。

上記を踏まえ、提示されている情報からはインデックス等の情報はありませんが、結果からの推測で、

SELECT a.*, b.name, c.name FROM
(
    SELECT * FROM A AS child
    WHERE child.b_id = X
    AND child.c_id = Y
) AS a
INNER JOIN B AS b ON a.b_id = b.id
INNER JOIN C AS c ON a.c_id = c.id
WHERE a.name LIKE '%??%'
ORDER BY a.id　LIMIT 10

のようにすると改善されるかもしれません。

Comments

[WanijimaAgito]

ご回答有難う御座います、ご回答のクエリに変更したところ、実行時間が1秒ほど増加致しました。
MySQLのEXPLAINを徹底解説!!　について参考にさせて頂き、調査を進めたいと思います、
有難う御座います。