Нужны сводные данные и отличные данные, я должен использовать 2 запроса или обработать сотни тысяч строк? (лучшая практика)

Question

У меня есть 2 таблицы 1. Первая таблица содержит перспективы, статус их обработки и полученный ими почтовый код (смотрите его как внешний ключ) 2. Вторая таблица содержит письма, проиндексированные с кодом электронной почты

Мне нужночтобы отобразить несколько диаграмм о сотнях тысяч потенциальных клиентов, я подумал о совокупном запросе (получить данные группы по месяцам, статус счета положительный, статус счета отрицательный, между начальной и конечной датой и т. д.) Результат довольно короткий и простой, и яможно использовать его непосредственно в диаграммах:

[ "2019-01" => [ "WON" => 55000, "LOST" => 85000, ...],
 ...
]

Затем меня попросили добавить фильтр с почтой (код и метка человека), чтобы пользователь выбрал его из поля множественного выбора.Я могу справиться с написанием запроса (запросов), но мне интересно, каким образом я должен использовать.

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

Я знаю кодирование, но у меня мало знаний о производительности.Теоретически я не должен использовать 2 запроса об одних и тех же данных, но обрабатывать все эти строки с помощью php, когда mysql может сделать это лучше, выглядит как ... "overkill".

Есть ли лучшая практика?

Answer 1

У меня есть много страниц PHP, которые имеют десятки запросов, поддерживающих их, и они выполняются достаточно быстро. Когда страница не работает быстро, я сосредотачиваюсь на самом медленном запросе; Я не играю в игры на PHP. Но я избегаю выполнения запроса, который попадает в сотни тысяч строк; это будет "слишком" медленно. Некоторые вещи ...

• Может быть, я найду способ агрегировать данные, чтобы избежать большого сканирования.
• Возможно, я перенесу большой запрос на вторую страницу - это позволит избежать наказания за ненужного пользователя.
• Может быть, я разбью большое сканирование, так что пользователь должен попросить куски, не построить страницу с 100K строк. Нумерация страниц не хороша для такого количества строк. Итак ...
• Может быть, я буду динамически создавать индекс для второго уровня страниц.

Чтобы обсудить это далее, предоставьте SHOW CREATE TABLE, некоторые SELECTs (не волнуйтесь о том, насколько они плохие; мы расскажем вам) и макеты страниц.