Почему запрос с count долго выполняется?

Question

[xiiicool]

база mysql 8 движок InnoDb, поле fileDate тип date, партиции на каждый день, индекс на fileDate стоит
запрос

SELECT cdrs.fileDate, count(*)
FROM billing_api.cdrs
WHERE fileDate >= '2024-03-18'
  AND fileDate <= '2024-03-24'
GROUP BY fileDate;

время выполнения без count 100ms с count 1 минута 50 сек

результат explain
1, 'SIMPLE', 'cdrs', '...', 'range', 'fileDate', 'fileDate', '3', null, 46678961, 100, 'Using where; Using index'
результат EXPLAIN analyze

-> Group aggregate: count(0)  (cost=14066345.63 rows=46678961) (actual time=19262.629..117008.029 rows=7 loops=1)
    -> Filter: ((cdrs.fileDate >= DATE'2024-03-18') and (cdrs.fileDate <= DATE'2024-03-24'))  (cost=9398449.53 rows=46678961) (actual time=1.198..108947.804 rows=97238448 loops=1)
        -> Covering index range scan on cdrs using fileDate over ('2024-03-18' <= fileDate <= '2024-03-24')  (cost=9398449.53 rows=46678961) (actual time=1.195..92245.365 rows=97238448 loops=1)

Comments

[alexalexes]

без count 100ms

А точно не top столько-то записей получаете? А то 97238448 записей за 100 мс точно полностью не выбрать.
Покажите план запроса без count,
и еще план и время такого запроса:

SELECT distinct cdrs.fileDate
FROM billing_api.cdrs
WHERE fileDate >= '2024-03-18'
  AND fileDate <= '2024-03-24'

PS: Вообще, для классического запроса тяжело агрегировать на таком временном срезе ~100 млн. записей, нужно использовать либо отдельные таблицы для подготовки отчетов, либо специальные системы для сбора статистики.

[Akina]

Ну если партиции на каждый день - то почему запрос недельный? Сервер - он же тупой, и у него не хватит мозгов понять, что каждая группа в своей партиции. Как итог - сперва всё в кучу, а потом сортировка и подсчёт.

Делай отдельные COUNT(*) по партициям (что, кстати, позволяет и соотв. хинт воткнуть), а потом UNION ALL. А если такого типа запросы частые - то вообще используй предагрегацию.

движок InnoDb, поле fileDate тип date, партиции на каждый день, индекс на fileDate стоит
запрос

SHOW CREATE TABLE - в текст вопроса.

[xiiicool]

alexalexes, 82ms
EXPLAIN
'range', 'fileDate', 'fileDate', '3', null, 7, 100, 'Using where; Using index for group-by'
EXPLAIN ANALYZE
-> Filter: ((cdrs.fileDate >= DATE'2024-03-18') and (cdrs.fileDate <= DATE'2024-03-24')) (cost=9.45 rows=7) (actual time=2.072..7.936 rows=7 loops=1)
-> Covering index skip scan for deduplication on cdrs using fileDate over ('2024-03-18' <= fileDate <= '2024-03-24') (cost=9.45 rows=7) (actual time=1.930..7.789 rows=7 loops=1)

[alexalexes]

У вас редактор запросов все таки дописывает limit 7, поэтому простые запросы без прописывания limit нельзя оценить простым запуском.

[xiiicool]

alexalexes, 7 разве не количество записей в результате ?

[Дмитрий]

Можно попробовать дату через BETWEEN указать

[alexalexes]

Я думаю, нужно запустить пересчет индекса по fileDate, если по схожим интервалам времени не получалось никогда столько записей.
xiiicool, rows - это кол-во записей, которые будут перебраны для проверки условий.
У вас реально в этом промежутке времени может быть ~100 млн. записей?

[xiiicool]

alexalexes, да примерно в день 15-20 млн

[Akina]

Обратите внимание.

Без группировки:

Covering index skip scan for deduplication on cdrs using fileDate over ('2024-03-18' <= fileDate <= '2024-03-24')

С группировкой:

Covering index range scan on cdrs using fileDate over ('2024-03-18' <= fileDate <= '2024-03-24')

То, что я и говорил - при простой выборке используется partition pruning, но во время группировки он благополучно херится. И, как итог - сортировка 50 млн. записей.

Answer 1

[Тимофей]

Потому что идёт подсчет количества записей, по этой же причине на многих сайтах отсутствует пагинация с номерами страниц, только вперёд и назад или подгрузка записей

Comments

[xiiicool]

как то можно вычислять сразу количество другим методом без созданий новой таблицы?

Answer 2

[Hlapchynya]

Попробуй заменить count(") на сount(1)

Comments

[Василий Дёмин]

В mysql это значения не имеет

Answer 3

[Ambulate]

Сделай подзапрос, и поверх него сеэделай каунт

Answer 4

[Medicavt]

Там же индекс по полю группировки. Без count выводится просто distinct от фильтра по индексу, все миллионы записей не поднимаются с диска. А с count надо поднять все фильтрованные записи и посчитать кол-во для каждой уникальной даты.

Answer 5

[coodi]

Можно сделать индекс по датам?

Answer 6

[Валентин]

Как на счет

select count(t.fileDate) cnt, t.fileDate 
from (select cdrs.fileDate from cdrs.fileDate 
where fileDate >= '2023-03-18'
  and fileDate <= '2024-03-24'
) as t
group by fileDate;

То есть сначала фильтруем, потом группируем. Мне видится так должно работать оптимальнее.

Comments

[xiiicool]

ещё дольше, > 2 минут

[Валентин]

А что, если сделать составной индекс id + fileDate

[xiiicool]

у меня uuid

Answer 7

[Emil Revencu]

Не пробовали использовать SQL_CALC_FOUND_ROWS?

Comments

[xiiicool]

1 мин 40 сек на 1 день, при count(*) 10 сек на 1 день