Есть ли способ улучшить производительность GROUP BY на этом?

Question

У меня простая проблема, или, по крайней мере, симптом проблемы прост. Следующий запрос является молниеносным без GROUP BY (0,15 секунды), но супер медленным с GROUP BY (более 100 секунд). Есть ли способ улучшить эту ситуацию?

  SELECT a.id, SUM(t.amount)
    FROM account_transaction t
    JOIN transaction_code tc ON t.transaction_code_id = tc.id
    JOIN account a ON t.account_number = a.account_number
    JOIN account_northway_product anp ON anp.account_id = a.id
    JOIN northway_product np ON np.id = anp.northway_product_id
   WHERE 1
     AND np.code != 'O1'
     AND tc.code IN (0, 20, 40)
GROUP BY a.id

Редактировать: Когда я делаю EXPLAIN в версии запроса GROUP BY, все выглядит хорошо, кроме одной строки:

select_type: simple
table: tc
type: index
possible_keys: PRIMARY,code,code_2
key: code
key_len: 257
ref: NULL
rows: 30
Extra: Using where; Using index; Using temporary; Using filesort

Из того, что я мало понимаю о EXPLAIN, key_len плохо, потому что это долго. «Использование временных; Использование файловой сортировки;» тоже плохо. Полагаю, я мог бы сделать одну вещь - уменьшить длину transaction_code.code, поскольку мне, вероятно, не понадобится больше 3 символов. Я не знаю, что делать с "Использовать временные; Использование сортировки;" хотя.

Answer 1

Возможно (?) Планировщик запросов может их убрать, но, похоже, у вас есть таблицы, которые вам не нужны в вашем запросе. Также реорганизовал объединения, чтобы учетная запись была указана первой.

SELECT a.id,
       SUM(t.amount)
  FROM 
    account a
        INNER JOIN account_northway_product anp ON anp.account_id = a.id 
            INNER JOIN northway_product np ON np.id = anp.northway_product_id
        INNER JOIN account_transaction t ON t.account_number = a.account_number         
            INNER JOIN transaction_code tc ON t.transaction_code_id = tc.id
 WHERE 
   np.code != 'O1'
   AND tc.code IN (0, 20, 40)
 GROUP BY a.id

Answer 2

сильно зависит от настроек вашей базы данных

Я предлагаю выполнить EXPLAIN для этого запроса и проанализировать вывод

. Вы можете пошагово удалить все соединения, которые выполняются достаточно быстро, и сосредоточиться на тех, которыене - проще увидеть, что нужно индексировать таким образом

стремиться к тому, чтобы при каждом соединении сканировалось менее 10000 строк

Редактировать: в отношении результатов объяснения - какой тип tc.codeстолбец?вы использовали целые числа в условии:

AND tc.code IN (0, 20, 40)

, а если tc.code - varchar, то использование индекса нарушено