回答編集履歴
3
推敲
answer
CHANGED
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
これを、`location_id`, `product_id`単位で集計としていますが、じゃあ、`引当総数`と`ロケ内総在庫数`はどんな集計されているの？って事です。これらは集計されず適当な何れかの値が採用されています。
|
|
12
12
|
相関問い合わせなので、それらの相関内の何れかの値が使用されていますが、何れも同じ値なので、求めたいものと同じになっているに過ぎません。
|
|
13
13
|
|
|
14
|
-
結果的にサブクエリーをさらに集計するような仕組みが働いて
|
|
14
|
+
結果的にサブクエリーをさらに集計するような仕組みが働いて、遅いのではないかと思われます。
|
|
15
15
|
基本に忠実に、SQLを組み立てると、必要なインデックスも明確になると思います。
|
|
16
16
|
|
|
17
17
|
性能が改善するかどうかわかりませんが、素直にキーを揃えるように組み立てると以下のようなSQLになるのではないかと。
|
2
推敲
answer
CHANGED
|
@@ -14,7 +14,7 @@
|
|
|
14
14
|
結果的にサブクエリーをさらに集計するような仕組みが働いているので、遅いのではないかと思われます。
|
|
15
15
|
基本に忠実に、SQLを組み立てると、必要なインデックスも明確になると思います。
|
|
16
16
|
|
|
17
|
-
性能が改善するかどうかわかりませんが、素直に組み立てると以下のようなSQLになるのではないかと。
|
|
17
|
+
性能が改善するかどうかわかりませんが、素直にキーを揃えるように組み立てると以下のようなSQLになるのではないかと。
|
|
18
18
|
```SQL
|
|
19
19
|
select stk.location_id AS 'ロケーションID'
|
|
20
20
|
, stk.product_id AS '商品ID'
|
1
追記
answer
CHANGED
|
@@ -1,7 +1,17 @@
|
|
|
1
1
|
`引当総数`や`ロケ内総在庫数`は`location_id`と`product_id`の組み合わせで一意であったり、値が変わらない為、MySQLの仕様（[12.19.3 MySQL での GROUP BY の処理](https://dev.mysql.com/doc/refman/5.6/ja/group-by-handling.html)）によって容認された結果に過ぎません。
|
|
2
2
|
※他のDBMSなら文法エラー
|
|
3
|
+
説明します。
|
|
4
|
+
先ず集計前の状態の以下のSQLは正しい結果だと思います。
|
|
5
|
+
```SQL
|
|
6
|
+
SELECT location_id, product_id, stock_num
|
|
7
|
+
, IFNULL((SELECT SUM(bst.bought_num) FROM BoughtStock bst WHERE bst.stock_id = stk.stock_id), 0) AS '引当総数'
|
|
8
|
+
, (SELECT SUM(stk2.stock_num) FROM Stock stk2 WHERE stk2.location_id = stk.location_id) AS 'ロケ内総在庫数'
|
|
9
|
+
FROM Stock
|
|
10
|
+
```
|
|
11
|
+
これを、`location_id`, `product_id`単位で集計としていますが、じゃあ、`引当総数`と`ロケ内総在庫数`はどんな集計されているの？って事です。これらは集計されず適当な何れかの値が採用されています。
|
|
12
|
+
相関問い合わせなので、それらの相関内の何れかの値が使用されていますが、何れも同じ値なので、求めたいものと同じになっているに過ぎません。
|
|
3
13
|
|
|
4
|
-
サブクエリーをさらに集計するような仕組みが働いているので、遅いのではないかと思われます。
|
|
14
|
+
結果的にサブクエリーをさらに集計するような仕組みが働いているので、遅いのではないかと思われます。
|
|
5
15
|
基本に忠実に、SQLを組み立てると、必要なインデックスも明確になると思います。
|
|
6
16
|
|
|
7
17
|
性能が改善するかどうかわかりませんが、素直に組み立てると以下のようなSQLになるのではないかと。
|