Django ORMでdistinct()が効いてるはずなのに重複する。犯人はMySQLだった話

開発中に、

1
あ？distinct入れてんねんけど。
2

3
いやいや。JOINで増えてるのは分かる。
4

5
だからdistinct入れてんねん。きみdistinctの意味わかってる？

みたいなことをひとり心の中で言ったことがある人は、たぶんこの記事の読者である。

今回遭遇したのは、

「distinct()してるのに同じデータが返ってくる」

という謎現象。

最終的にはDjangoのバグでもなく、自分のコードの単純ミスでもなく、MySQLの仕様に綺麗にハマっていた。

しかもエラーは出ない。

静かに壊れる。

こういうやつが一番怖い。

現象#

事例データ周りを触っていて、属性一覧を取得していた。

1
attrs_qs = (
2
    Attribute.objects
3
    .filter(
4
        attribute_group__in=[g['id'] for g in groups],
5
        active=True
6
    )
7
    .order_by(
8
        'attribute_group__item_pf_atr_group__sort',
9
        'attribute_group__sort',
10
        'sort',
11
        'id'
12
    )
13
    .values(
14
        'id',
15
        'value',
16
        'attribute_group_id'
17
    )
18
    .distinct()
19
)

見た感じ特に問題なさそう。

実際、

JOINで増えるかもしれんし、とりあえずdistinct()

みたいなコードはよく見る。

ところが結果を見ると、

1
[
2
    {
3
        "id": 10,
4
        "value": "3000"
5
    },
6
    {
7
        "id": 10,
8
        "value": "3000"
9
    }
10
]

みたいな状態になる。

いや、なんでやねん。

distinctどこ行った。

最初に疑ったこと#

まず疑ったのはJOIN。

JOIN先が増えてる？
中間テーブルがおかしい？
related_nameミス？
LEFT JOINのせい？

この辺を順番に見ていく。

実際、JOINで件数は増えていた。

でも、

1
JOINで増えてる
2
↓
3
distinctがある
4
↓
5
だから潰れるはず
6
↓
7
なんで残ってる？

になる。

ここで少しずつ嫌な予感がしてきた。

SQLを見たら違和感があった#

こういう時はDebug Toolbar。

SQLを開く。

1
SELECT DISTINCT
2
       fjs_attribute.id,
3
       fjs_attribute.value,
4
       fjs_attribute.attribute_group_id,
5
       fjs_itempfatrgroup.sort,
6
       fjs_attributegroup.sort,
7
       fjs_attribute.sort

・・・

ん？

お前誰やねん#

values()で指定したのはこれだけ。

1
.values(
2
    'id',
3
    'value',
4
    'attribute_group_id'
5
)

なのにSQLを見ると、

1
fjs_itempfatrgroup.sort
2
fjs_attributegroup.sort
3
fjs_attribute.sort

がSELECTされている。

いや、お前誰やねん。

呼んでないやろ。

最初はDebug Toolbarの表示の問題かと思った。

でもSQL全文を見てもちゃんとSELECTされている。

勝手に増えている。

ここでだいぶ嫌な予感がしてきた。

犯人はMySQLだった#

調べていくと原因はMySQLの仕様だった。

MySQLでは、

1
SELECT DISTINCT ...
2
ORDER BY ...

を使う場合、

ORDER BYに使用するカラムをSELECT対象に含める必要がある。

そのためDjangoが内部的にORDER BY用のカラムを追加していた。

つまりORM上は、

1
.values(
2
    'id',
3
    'value',
4
    'attribute_group_id'
5
)
6
.distinct()

に見えていても、

実際には、

1
id
2
value
3
attribute_group_id
4
itempfatrgroup.sort
5
attributegroup.sort
6
attribute.sort

まで含めてDISTINCT判定されていた。

本当に起きていたこと#

例えばこんなデータ。

id	value	pf_sort
10	3000	1
10	3000	2

Python側から見ると、

1
{
2
    "id": 10,
3
    "value": "3000"
4
}

しか見えない。

だから同じデータに見える。

でもMySQLから見ると、

1
(10, 3000, 1)
2
(10, 3000, 2)

なので別行。

distinct()は壊れていない。

ちゃんと働いている。

ただ、自分が思っていた対象に対してではなかった。

倍になってる#

ここで全てが繋がった。

JOINも正常。

Djangoも正常。

MySQLも正常。

distinct()も正常。

なのに結果だけがおかしい。

返ってきたデータを見る。

1
[
2
    {"id": 10, "value": "3000"},
3
    {"id": 10, "value": "3000"},
4
]

・・・

倍やん。

完全に倍やん。

倍返しである#

distinctしたはずなのに、

データが倍になって返ってくる。

しかもエラーも出ない。

静かに。

ログにも残らず。

倍返しされる。

ということで現場ではこの現象をこう呼ぶこととする。

半沢バグ#

Django + MySQL において、 values().distinct().order_by() の組み合わせにより、 ORDER BY用カラムがDISTINCT判定へ巻き込まれ、見た目上同じデータが倍返しされる現象。

危険なのは、

エラーにならないこと。

件数集計。

価格計算。

組み合わせ生成。

こういうところで起きると結構しんどい。

対策#

今回のケースではGROUP BY寄りに寄せた方が安全そうだった。

1
from django.db.models import Min
2

3
attrs_qs = (
4
    Attribute.objects
5
    .filter(...)
6
    .values(
7
        'id',
8
        'value',
9
        'attribute_group_id'
10
    )
11
    .annotate(
12
        pf_sort=Min(
13
            'attribute_group__item_pf_atr_group__sort'
14
        )
15
    )
16
    .order_by(
17
        'pf_sort',
18
        'id'
19
    )
20
)

あるいは、

1
distinct()
2
+
3
values外のorder_by

を見たら一度警戒する。

これだけでもだいぶ違うと思う。

まとめ#

今回学んだことはシンプルだった。

distinct()を見たら安心してしまう。

でも本当に見るべきなのは、

何に対してDISTINCTが掛かっているか。

次また似た現象を見たら、

まずSQLを見る。

そして知らんカラムがおったら疑う。

今後これを

黒崎チェック

と呼ぶことにした。

もしSELECT句に見覚えのないカラムが紛れ込んでいたら、

まず黒崎チェック。

1
☑ values()に書いたの？
2
☑ annotateしたの？
3
☑ order_byで使ってないわよね？
4
☑ じゃあお前誰？

もしSELECT句に見覚えのないカラムが紛れ込んでいたら、

たぶん半沢が始まっている。