Форум пользователей MySQL

Мне кажется, задача сильно упростилась бы, если бы было «в конкретную минуту». В чем смысл скользящего окна? Мы на выходе ожидаем получить всё равно конечное количество строк (== не непрерывное), поэтому мы в любом случае будем группировать по фиксированным диапазонам времени. Ну и тогда оно решится одним полным сканом с группировкой по функции.

Ну и для наглядности пример. Пусть есть всего три события — 0:00, 0:30 и 1:00. Что мы ожидаем получить на выходе? Если [2, 1], то мой способ годится. Ваш способ, кстати, посчитает 1:00 трижды, что кажется неправильным.

Спасибо за ответы!
1. Группировка по минутам может дать точность в 50%. Это многовато для моей задачи. Кстати, это было первое мое решение.
2. Использую поле DATETIME.
3. Мой алгоритм оказался не только медленным, но не точным. Если в один момент есть два (несколько) события, то результат будет задваиваться и т.д. Для меня это было неожиданно, не думал, что одновременно возможно два события. Возможно это связано с группировкой по дате.
В связи с тем, что события, в основном, идут последовательно я использовал ID (первичный ключ).

Где @MinEvent - минимальное число - количество событий в минуту, которое не может наступить.
Мало того, что он дает производительность на два порядка лучше, но он исключает ошибки, когда события могут быть в один и тот-же момент (как?!).
Только я не понял, почему нужна группировка по полю t.d если есть группировка по ID? Но если ее не делать, что запрос выполняется очень долго.

Отредактированно klow (07.06.2018 07:15:34)

rgbeast написал:

Как задается величина @MinEvent?

Просто константа.

rgbeast написал:

Решение опирается на то, что id в базе должны идти подряд без пропусков, что не гарантировано стандартом.

Да, согласен, в общем случае это неприменимо, но в моем вполне допустимо.

Все, окончательно запутался.
Сделал ограничение по дате (t.d > '2018-06-05' ) для первого случая, EXPLAN не изменился, но это предсказуемо - там нет индекса.
Сделал ограничение по ID (идут последовательно) t.id > 764900 AND c.id > 764900
EXPLAN
id    select_type    table    type    possible_keys    key    key_len    ref    rows    Extra
1    SIMPLE    t    range    PRIMARY    PRIMARY    4    (null)    11448    Using where; Using temporary; Using filesort
1    SIMPLE    c    range    PRIMARY    PRIMARY    4    (null)    11448    Using where
Тоже все предсказуемо, но!
Время выполнения для ограничения по дате порядок(!) меньше ограничения по ID!? Это как?
кеш отключен SQL_NO_CACHE

Отредактированно klow (07.06.2018 10:25:04)

не дождался я результата, на 10-ой минуте прервал.
id    select_type    table    type    possible_keys    key    key_len    ref    rows    Extra
1    PRIMARY    <derived2>    ALL    (null)    (null)    (null)    (null)    14952    Using temporary; Using filesort
2    DERIVED    t    range    PRIMARY    PRIMARY    4    (null)    14952    Using where; Using temporary; Using filesort
3    DEPENDENT SUBQUERY    c    ALL    PRIMARY    (null)    (null)    (null)    740181    Using where

Запрос, который я использую выполняется за 1,5 сек.
Остается непонятным:
1. Почему нужна группировка по дате?
2. Почему ограничение по дате (нет индекса) работает лучше чем ограничение по первичному ключу?

Отредактированно klow (07.06.2018 21:46:56)