Посчитайте с предложением where только 100k последних записей в большой таблице MySQL

Question

В нашей базе данных есть таблица с более чем 20 миллионами записей. каждый день эта таблица растет в среднем на 100 000 записей. Мне нужно выполнить подсчет для этой таблицы, самое большее, мне нужно сканировать только 24-часовые записи (в среднем 100 КБ). Мой общий подход:

1. Получить последний идентификатор таблицы (Long maxId = SELECT MAX(acc.id) FROM MyTable as acc WHERE 1) так как это очень быстро.
2. Рассчитайте интервал: Long tolerableMin = maxId - 100000.
3. Затем выполните секунду SELECT count(*) FROM MyTable as acc " + " WHERE acc.X = 'SomeValue' + " AND acc.Y = 'OtherVal' + " AND acc.id > " + tolerableMin + " ORDER BY id DESC.

Это среднее время выполнения ~ 2 секунды Когда я выполняю прямой подсчет (x) с предложением where, но без условия для acc.id > X, запрос зависает более чем на 15 секунд. Мой вопрос:

1. Является ли этот подход оптимальным?
2. Я что-то пропустил? какие-нибудь подсказки?

Примечание: я использую это в бэкэнде Java / Hibernate и MySQL в качестве сервера БД.

Answer 1

План A: INDEX(x,y,id) и выбрасывание ORDER BY.

План B: Вы хотите только последние 24 часа, но где временная метка? Может быть, это x? затем INDEX(timestamp, y) и подбросьте ORDER BY.

Plan C: создайте и поддерживайте «Сводную таблицу»: http://mysql.rjweb.org/doc.php/summarytables

Answer 2

Это идеальный сценарий для того, чтобы вообще не считать Я бы предпочел создать триггер для заполнения таблицы с отдельным счетчиком, если вам не нравятся триггеры, подумайте о том, чтобы иметь таблицу и задание, чтобы время от времени заполнять его в фоновом режиме. В реальной жизни очень мало случаев, когда вам действительно нужны данные в реальном времени, иногда от 30 минут до нескольких часов вполне достаточно для обновления такого счетчика. Другой идеей мозгового штурма было бы иметь solr или любой другой номер SQL, чтобы индексировать все эти данные, которые вам нужно сосчитать, в хранилище без sql, тогда счетчик будет намного быстрее Я не вижу лучшего способа ускорить его, используя обычный счет на таком большом SQL столе