Ну то есть больше 20%. Собственно работает по доке.
Вот explain запроса с кол-вом результатов примерно 1%:
А здесь индекс автоматом подключился все дела.
Слушайте - ну как бы вариант реально партицировать это дело. Разбить by range так что бы такие urlId с таким количеством записей вывались в отдельные партиции. Вопрос только как дальше будут распределяется данные - будет ли держаться такие пики записей у каких то отдельных урлов - или в дальнейшем все сгладится. Во втором случае - может и стоит гвоздями через force index прибить - или посмотреть можно ли через какой то параметр мускула сдвинуть эти 20%
Это нужно создавать новый запрос где дергать данные конкретного пользователя. А так же надо прочитать про prepared statement потому что в данный момент никакой авторизации нет, можно авторизоваться без логина и пароля
Ex1st, З.Ы Ну а так вообще я бы попробовал выкинуть все таблицы к херам и попробовал бы работать с 2 таблицами
b_iblock_element_prop_s1 FPS0
b_catalog_product as PRD
попробовать добиться с ними улучшения - а дальше уже joinить к ним другие, хотя идей как улучшить сортировку по таким полям у меня нет.
Ex1st, в рамках этого запроса MySQL у меня идей кроме как поиграться с sort_buffer_size - нет. Может у кого другого будут.
В рамках вообще - как то хранить подготовленные данные и работать уже с ними.
Ex1st, просто в чем прикол - понятно что когда вы добавляете order by базе надо выбрать все записи что бы отсортировать их и только после этого сделать limit. Понятно что order by можно подсунуть индекс и он будет его использовать. Но у вас первое поле AVAILABLE состоит из двух значений Y, N - делать по нему индекс бесмысленно а дальше идет другая таблица другое поле.
Ex1st, а order by в запрос добавьте, не только в эксплейн ( картинка которой у меня кстати обрезалась и поле extra не видна). Мужики должны знать почему вы ордербаети и в каком порядке. Может быть это поле можно впихнуть в индекс последним и в индексе указать порядок
ag033, порядок то должен быть обратным. Мы работаем с questions, если вы взглянете на sql запрос вы увидите что мы делаем
select * from questions;
И дальше идем
select * from questions
join test_quesion on test_question.question_id = questions.id
join tests on tests.id = test_question.test_id
join lessons on lessons.id = tests.lesson_id
join modules on modules.id = lessons.module_id;
А таблица courses нам уже нахрен не нужна - ибо у нас в таблице modules есть поле course_id
ag033, Общий смысл такой. У нас таблица questions не имеет никакой связи с курсами. Следовательно нам нужно задойжнить все до ситуации когда мы сможем связать с курсами.
Questions идет сама во from, дальше джойним таблицу связку с tests, потом сами tests, tests у нас связаны с lessons - джойним lessons, lessons у нас связан с modules - джойним его, а вот модули уже знают про courses потому что у них ключ course_id.
ag033, я честно говоря в порядке таблиц и их нужности на вас полагался. Вижу надо самому. Вы приведите функции связки -я тогда смогу хоть по коду порядок выставить
