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

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

ただいまの
回答率

90.34%

  • MySQL

    7420questions

    MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

MysqlのSELECT句中でサブクエリのWHERE条件

解決済

回答 2

投稿 編集

  • 評価
  • クリップ 0
  • VIEW 1,053

sanapapa

score 14

例えば下記のような2つのテーブルがあるとします。

Stock(在庫テーブル)

CREATE TABLE `Stock` (
    `stock_id` INT(11) NOT NULL AUTO_INCREMENT,
    `location_id` INT(11) NULL DEFAULT NULL,
    `product_id` INT(11) NULL DEFAULT NULL,
    `stock_num` INT(11) NULL DEFAULT NULL,
    PRIMARY KEY (`stock_id`),
    INDEX `location_id` (`location_id`, `product_id`)
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
;
stock_id location_id product_id stock_num
1 100 1000 5
2 101 1001 3
3 102 2000 1
4 103 1000 1
5 104 3000 4
6 103 1001 3
7 100 1001 2
8 101 2000 4

BoughtStock(購入在庫)

CREATE TABLE `BoughtStock` (
    `stock_id` INT(11) NULL DEFAULT NULL,
    `bought_num` INT(11) NULL DEFAULT NULL,
    INDEX `stock_id` (`stock_id`)
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
ROW_FORMAT=COMPACT
;


※購入されるたびにレコードが挿入される(stock_idは重複する)

stock_id bought_num
1 1
1 1
4 1
1 1
2 1
2 1
3 1

このデータから↓のような結果を抽出しようとしています。
・ロケ、商品ごとの在庫総数
・引当総数(購入点数):そのロケのその商品が何点購入されているのかを抽出
・ロケ内総在庫数(商品問わず):ロケ内の在庫を全商品ですべて合算する

ロケーションID 商品ID 在庫数 引当総数 ロケ内総在庫数
100 1000 5 3 7
100 1001 2 0 7
101 1001 3 2 7
101 2000 4 0 7
102 2000 1 1 1
103 1000 1 1 4
103 1001 3 0 4
104 3000 4 0 4
SELECT
      stk.location_id AS 'ロケーションID'
    , stk.product_id AS '商品ID'
    , SUM(stk.stock_num) AS '在庫数'
    , IFNULL((SELECT SUM(bst.bought_num) FROM BoughtStock bst WHERE bst.stock_id = stk.stock_id), 0) AS '引当総数'
    , (SELECT SUM(stk2.stock_num) FROM Stock stk2 WHERE stk2.location_id = stk.location_id) AS 'ロケ内総在庫数'
FROM Stock stk
GROUP BY stk.location_id, stk.product_id
ORDER BY stk.location_id, stk.product_id

実行計画

id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY stk index location_id 10 8
3 DEPENDENT SUBQUERY stk2 ref location_id location_id 5 func 1 Using where
2 DEPENDENT SUBQUERY bst ref stock_id stock_id 5 func 1 Using where

上記のSQLで結果自体は問題ありませんし、EXPLAINで実行計画を取得してもインデックスも効いているのですが
実際何千行の大量データで抽出すると著しく速度が低下します。

SELECT句のサブクエリの項目を外すと速度は低下しません。

もしかしてSELECT句でサブクエリを使用する場合、上記SQLのような条件の書き方ではインデックスが効かない仕様なのでしょうか。

また、速度低下せずに抽出できるSQLを考案可能な方がいらっしゃいましたらご教示いただきたいです。
※BoughtStockはstock_idの重複があるため、単純なLEFT JOINでは「在庫数」など他の集計項目が倍々になります。

何卒宜しくお願い致します。

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

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

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

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • m.ts10806

    2018/11/14 16:26

    何の取得を目的としたクエリなのか解説を入れられたほうがリファクタリングもやりやすくなりますので、追記願います。

    キャンセル

  • sanapapa

    2018/11/14 16:32

    失礼いたしました、修正してみました。ご確認お願いします。

    キャンセル

  • Orlofsky

    2018/11/14 18:15

    質問にCREATE TABLE, CREATE INDEX や現状の実行計画も載せた方が適切なコメントが付き易いです。

    キャンセル

  • sanapapa

    2018/11/15 11:56

    ご指摘ありがとうございます。既にベストアンサーは選んでしまいましたが、参考までに記載させていただきました。

    キャンセル

回答 2

checkベストアンサー

+3

引当総数ロケ内総在庫数location_idproduct_idの組み合わせで一意であったり、値が変わらない為、MySQLの仕様(12.19.3 MySQL での GROUP BY の処理)によって容認された結果に過ぎません。
※他のDBMSなら文法エラー
説明します。
先ず集計前の状態の以下のSQLは正しい結果だと思います。

SELECT location_id, product_id, stock_num
     , IFNULL((SELECT SUM(bst.bought_num) FROM BoughtStock bst WHERE bst.stock_id = stk.stock_id), 0) AS '引当総数'
     , (SELECT SUM(stk2.stock_num) FROM Stock stk2 WHERE stk2.location_id = stk.location_id) AS 'ロケ内総在庫数'
FROM Stock


これを、location_idproduct_id単位で集計としていますが、じゃあ、引当総数ロケ内総在庫数はどんな集計されているの?って事です。これらは集計されず適当な何れかの値が採用されています。
相関問い合わせなので、それらの相関内の何れかの値が使用されていますが、何れも同じ値なので、求めたいものと同じになっているに過ぎません。

結果的にサブクエリーをさらに集計するような仕組みが働いて、遅いのではないかと思われます。
基本に忠実に、SQLを組み立てると、必要なインデックスも明確になると思います。

性能が改善するかどうかわかりませんが、素直にキーを揃えるように組み立てると以下のようなSQLになるのではないかと。

select stk.location_id AS 'ロケーションID'
     , stk.product_id AS '商品ID'
     , stk.prdct_stock_sum AS '在庫数'
     , coalesce(stk.prdct_bought_sum, 0) AS '引当総数'
     , stk_loc.loc_stock_sum AS 'ロケ内総在庫数'
from (
        select location_id, product_id, sum(stk_stock_sum) as prdct_stock_sum, sum(bought_sum) as prdct_bought_sum
        from (
                select location_id, product_id, stock_id, SUM(stock_num) AS stk_stock_sum
                FROM Stock stk
                group by location_id, product_id, stock_id
            ) stk 
            left join (
                select stock_id, SUM(bought_num) as bought_sum FROM BoughtStock group by stock_id
            ) bst
            on  stk.stock_id=bst.stock_id
        group by location_id, product_id
    ) stk inner join (
        select location_id, sum(stock_num) as loc_stock_sum from Stock group by location_id
    ) stk_loc
    on  stk.location_id=stk_loc.location_id
ORDER BY stk.location_id, stk.product_id
CREATE TABLE Stock(stock_id int, location_id int, product_id int, stock_num int);
INSERT INTO Stock(stock_id, location_id, product_id, stock_num)
VALUES
    (1, 100, 1000, 5),
    (2, 101, 1001, 3),
    (3, 102, 2000, 1),
    (4, 103, 1000, 1),
    (5, 104, 3000, 4),
    (6, 103, 1001, 3),
    (7, 100, 1001, 2),
    (8, 101, 2000, 4)
;
CREATE TABLE BoughtStock(stock_id int, bought_num int);
INSERT INTO BoughtStock(stock_id, bought_num)
VALUES
    (1, 1),
    (1, 1),
    (4, 1),
    (1, 1),
    (2, 1),
    (2, 1),
    (3, 1)
;

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/11/15 13:03 編集

    パフォーマンスについては、プライマリーキーが設定されているかどうかは関係ありません。
    主に、条件(結合条件含む)や並びに関係している項目についてインデックスが設定されているかどうかです。集計などでは、集計する項目もインデックスに含まれていれば、インデックスのみで処理されるのでより高速です。
    今回は、既に適切なインデックスがあり、それを効率よく使うようにマッチングしたSQLに結果的になったという事です。
    実行計画では意図したインデックスが使用されているという事であったので、そうなるであろうと予想はしていましたが。

    キャンセル

  • 2018/11/15 13:34

    なるほど、create tableで重要なカラムでよくセレクトでhaving・group・whereを使うときにはindexもしっかり付けた方がいいよということですね。

    selectを三つだしていましたが、これはmysqLターミナルでは可能でPHPでは結果セットがあふれかえってしまうのであまり使えない方法ということになりますか?

    キャンセル

  • 2018/11/15 13:43 編集

    >indexもしっかり付けた方がいいよということですね。
    概ねそうです。ただ、インデックスを付けすぎると更新時のパフォーマンスは下がりますし、DISK資源も消費します。効果を見ながらというのも必要です。
    >結果セットがあふれかえって
    1回のSQLで返却される結果セットは一つですよ
    select毎に返却されるわけではありません。サブクエリーは単にネストした問い合わせですので。

    キャンセル

-2

stockテーブルの問題点

もし重複するのが困るなら、
insert into
を使わないことと、
なにが唯一(
primary keyなのかがはっきりしていないですよ。

もしまだ表の再構築が可能ならcreate tableを実行して、どのカラム(列)を唯一にするのか設定しなおしてください。

もし、際構築が不可能なら、
alter table
で唯一を設定してください。

もしくは唯一がすでに設定されているなら質問本文を修正してください。

現状での対策

現状ではhavingやgrouping区を使って対処するしかない気がします。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

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

  • ただいまの回答率 90.34%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

同じタグがついた質問を見る

  • MySQL

    7420questions

    MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。