Помогите оптимизировать (переписать) SQL запрос

В данном случае можно добавить поле partners_id в mailmaster_users и склеивать по нему. Но лучше вынести настройки в нормальную табличку с адекватными связями.

Я предпочитаю хранить настройки/поля/etc в табличке вида id_сущности|название_поля|значение_поля, можно повесить индекс на значение поля и составные индексы на сущность+название+значение, сущность+название

---------- Добавлено 21.07.2016 в 19:38 ----------

Ну вот, а тут всего 3697 строк обрабатываеться и везде с индексами, как положено

Хоспади, да при чем тут индексы при 7000 строках?

Я и так вижу, что вы в SQL разбираетесь, но о чем речь?

При чем тут индексы?

---------- Добавлено 21.07.2016 в 19:04 ----------

Aisamiery индексы эффективно на сотнях миллионов записей работают. Вот так.

Остальное - просто фигня полнейшая.

Из 7000 строк, выбираеться 3697 строк по where, а потом каждая из этих строк в джоин сравнивается с !каждой строкой во второй таблице, то есть 8738 раз, как думаете это быстро? Индексы помогают уменьшить результатирующую выборку для сравнений, у ТС на первом скрине ключ email в столбце ref имеет значение NULL, что говорит о том, что сравнивается со всей таблицей и чем больше таблица, тем дольше будет работать запрос при том по экспоненте, тем более IN работает только с проиндексированными полями, иначе он убивает любой селект - так в документации написано, не мои слова )))

---------- Добавлено 21.07.2016 в 20:12 ----------

Поверьте, вы ошибаетесь :)

вы поаккуратней с такими заявками в цивилизованном обществе...

Magistr, Моё предложение остаеться в силе, сделайте несколько запросов просто с ON email = email_N, а потом данные объедините в приложении

Все же поняли :)

Когда речь идет уже про секунды - дело тут не в индексах, а в квалификации программистов.

До этого движок SQL прекрасно справляется.

Basilisk, что-то я совсем запутался. Так вы согласны, что вам нужны индексы в любом случае, если данное поле используется в where или join?

Dinozavr

нужны, естественно (хоть и не в любом), а вы какого ответа ожидали? :)

Речь о решении проблемы.

Если в таблице 7000 строк (а не сотни миллионов), а запрос при этом выполняется 35 секунд - то дело не в индексах.

Просто у начинающих SQL разработчиков это частая проблема - если что-то не так, надо срочно куда-нибудь добавить индексы!

В любом случае нужны, если поле учавствует в фильтрации. Просто там много ньюансов, которые не знают начинающие разработчики, типо берется только первое поле за индекс или в выборке поля должны быть в том же порядке что и в составном индексе. Опять же индексы вредны в таблицах, где больше записи, чем чтение потому что перестроение индексов в такой таблице будет дольше чем селекты к ней. В остальных случаях они помогают при выборке сократить результатирующий набор для обхода. Почему ходит мнение, что индексы полезны на миллионах строк, тут все просто, mysql работает с большой таблицей блоками, то есть загрузили блок в память, проверили, выгрузили, загрузили новый блок в память, проверили, выгрузили и вот чтоб не грузить все блоки (а операция довольно дорогая), индексами находят нужный, но это, так сказать, лишь один из способов их применения, mysql использует деревья, то есть по индексам он может выбрать нужную ветку дерева и сократить порядок обхода в разы. Пример ТС, как раз когда из 2х табличек по 7000 записей получаеться выборка на 32 миллиона строк, ему конечно не помогут они, но вводить в заблуждение других участников форума не очень хорошо.

Вот я как раз об этом, просто вы за меня сами объяснили :)

---------- Добавлено 22.07.2016 в 10:54 ----------

MS SQL тоже так. Вернее наоборот - MySQL как MS SQL.

А так все по делу, не поспоришь :)