лучше запрос и текстовый explain запроса
Я бы начал смотреть с DISTINCT
с ним еще стало лучше, c GROUP BY было хуже
Сам запрос https://pastebin.com/B5qNTQRq Текстовый экспейн https://pastebin.com/Zh6tQDfL
Имеете в виду есть ли индекс на поле по которому DISTINCT?
Для начала посоветую прекратить ссылаться на оператора по ФИО. Во-первых, оно не уникально во-вторых можэт меняться.
Тут такая неприятная картинка что та таблица где и считаются вопросы по тексту ее больше ни как не связать с остальными, только по ФИО операторов . Голову ломаю как это обойти. Тоже самое касается и вопросов и ответов - их бы по айди считать. Но одниаковых вопросов и одинаковых ответов с разными айди много и я могу не знать когда добавят еще чтобы выборку поправить
Далее уж три запроса к serverate_otdel_mfc_results жэлательно объединить в один. Ну там, соединить результаты через конкатенирование с точкой, а на клиенте порезать. Или не на клиенте, а в вашэм внешнем селекте — он всё равно обработкой занимается. Я бы, конечно, всё вообще на join перевёл с подзапросов, но в таком простом случае эффективный план скорее всего будет один и тот жэ, так что это можно и не делать.
Нажаловаться на архитектора БД. Ну, как это так — оцэнивают оператора, а в базу трэш какой-то пишэтся! В концэ концов, дажэ в дате и номере рабочего места большэ толка! Кроме того, если первичка фиговая — то можно её приводить в приличный вид регулярными загрузками.
Ну и, если хотите именно быстро искать в табличке по operator_fio, date — то и индэкс должэн быть на operator_fio, date. Это независимо от всего предыдущего.
Понятно! спасибо большое за разъяснения! буду думать. Начну с индекса конечно
Обсуждают сегодня