Djangoでdistinct()しても重複するときに確認するポイント

Django ORMで、

1
.distinct()

を指定しているのに、なぜか同じデータが複数返ってくる。

そんなときは、JOINだけでなく**order_by()と実際に生成されているSELECT句**も確認した方がいい。

特に、

1
.values(...)
2
.order_by(...)
3
.distinct()

を組み合わせている場合は要注意。

values()に書いていないフィールドが、実際のSQLではSELECTされていることがある。

まず確認するポイント#

distinct()しているのに重複して見える場合、今回のケースでは次の部分がポイントになった。

1
.order_by(
2
    'attribute_group__item_pf_atr_group__sort',
3
    'attribute_group__sort',
4
    'sort',
5
    'id'
6
)
7
.values(
8
    'id',
9
    'value',
10
    'attribute_group_id'
11
)
12
.distinct()

注目するのは、values()とorder_by()で指定しているフィールドが違うこと。

values()は、

1
id
2
value
3
attribute_group_id

だけ。

一方、order_by()ではJOIN先を含む複数のsortを使っている。

この状態で実際に発行されるSQLを確認する。

実際に生成されたSQL#

今回、Django 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`
8
  FROM `fjs_attribute`
9
 INNER JOIN `fjs_attributegroup`
10
    ON (`fjs_attribute`.`attribute_group_id` = `fjs_attributegroup`.`id`)
11
  LEFT OUTER JOIN `fjs_itempfatrgroup`
12
    ON (`fjs_attributegroup`.`id` = `fjs_itempfatrgroup`.`attribute_group_id`)
13
 WHERE (
14
       `fjs_attribute`.`active` = 1
15
       AND `fjs_attribute`.`attribute_group_id` IN (6, 7, 8)
16
 )
17
 ORDER BY
18
       `fjs_itempfatrgroup`.`sort` ASC,
19
       `fjs_attributegroup`.`sort` ASC,
20
       `fjs_attribute`.`sort` ASC,
21
       `fjs_attribute`.`id` ASC

ORMではvalues()に指定していなかった、

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

までSELECTされている。

ここがポイント。

なぜdistinct()しても重複するのか#

例えばJOIN後のデータがこうなっていたとする。

id	value	attribute_group_id	item_pf_sort
10	3000	6	1
10	3000	6	2

values()だけを見ると、

1
10, 3000, 6
2
10, 3000, 6

なので同じデータに見える。

当然、

1
.distinct()

で1件になると思いたくなる。

ところが実際のSQLではitem_pf_sort相当のカラムもSELECTされている。

そのためDISTINCTから見ると、

1
10, 3000, 6, 1
2
10, 3000, 6, 2

となる。

これは別の行なので、両方残る。

Django側で結果を見るとvalues()で指定したフィールドだけが見えるため、

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

という同じデータが複数返ってきたように見える。

つまり、

distinct()が効いていないのではなく、DISTINCTの対象になっているカラムが想定より多い

という状態。

Debug Toolbarで確認する#

この現象を疑ったら、ORMだけを眺め続けるより実際のSQLを確認した方が早い。

Django Debug ToolbarなどでSQLを開いて、

1
SELECT DISTINCT ...

のSELECT部分を見る。

例えばORMが、

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

なのに、

1
SELECT DISTINCT
2
    id,
3
    value,
4
    attribute_group_id,
5
    some_sort,
6
    another_sort

となっていたら要注意。

values()に書いていないフィールドがDISTINCTの判定へ影響している可能性がある。

対処方法#

今回のように、

重複をまとめたい
JOIN先の値でも並べ替えたい

という場合は、単純なdistinct()ではなく、集約した値を使って並べる方法が考えられる。

例えばMin()を使う場合。

1
from django.db.models import Min
2

3
attrs_qs = (
4
    Attribute.objects
5
    .filter(
6
        attribute_group__in=[g['id'] for g in groups],
7
        active=True
8
    )
9
    .values(
10
        'id',
11
        'value',
12
        'attribute_group_id'
13
    )
14
    .annotate(
15
        pf_sort=Min(
16
            'attribute_group__item_pf_atr_group__sort'
17
        ),
18
        group_sort=Min(
19
            'attribute_group__sort'
20
        ),
21
        attr_sort=Min('sort'),
22
    )
23
    .order_by(
24
        'pf_sort',
25
        'group_sort',
26
        'attr_sort',
27
        'id'
28
    )
29
)

values()でグルーピングし、並び順に必要な値をMin()などで代表値として取得する形。

ただし、Min()を使えば常に正解というわけではない。

JOIN先に複数のsortが存在する場合、

どの値を並び順として採用したいのか

はデータ構造や仕様によって変わる。

最小値を使うのか、最大値なのか、そもそもJOINの条件を絞るべきなのかは個別に判断する必要がある。

distinct()しても重複するときのチェックポイント#

今回のケースから、まず確認したいのはこのあたり。

1
☑ JOINによって元データが複数行になっていないか
2

3
☑ values()には何を指定しているか
4

5
☑ order_by()でvalues()にないフィールドを使っていないか
6

7
☑ 実際のSELECT DISTINCTに何が含まれているか
8

9
☑ JOIN先のsortなど、行ごとに値が違うカラムがSELECTされていないか

特に重要なのは、ORMだけで判断しないこと。

1
.values('id', 'value')
2
.distinct()

だけを見ると、

「idとvalueでDISTINCTしている」

ように見える。

でも実際にDBへ送られているSQLがそうなっているとは限らない。

distinct()しているのに重複する場合は、

一度生成されたSQLのSELECT句を確認する。

これが一番手っ取り早い。

ORMが綺麗でも、SQLの裏側では知らんやつがSELECTに紛れ込んでいることがある。

実際にこの問題にハマって原因を調べた流れはこちら

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