Форум пользователей MySQL

Вы сортируете по вычисляемому полю, так что тут по любому будет filesort всего результата. Можно лишь вложенными запросами в части from заранее отсечь лишнее, т.е. вместо
   tyres t
использовать
(select from tyres order by price limit X) t

Аналогично и для wheels

X подбирается с запасом, вдумчиво глядя на данные

Тогда

Убрал UNION ALL, чтобы отбирались только уникальные строки. Добавил сортировку по ID товаров.

Странно, но когда я выставляю X = 21, все работает. И даже при разделении на страницы работает. X = 41, LIMIT 20,21 — результаты у обоих запросов одинаковы. +))

Теперь надо понять, где могут быть подводные камни. И надо просто осознать, почему все-таки работает.

Все работает. +)) Только не со временными таблицами.
Создание таблиц дубликатов занимает то время, которое потом экономится на новом объединяющем запросе.
Попа. +)))

О каких таблицах дубликатов идет речь?
Вы подразумеваете подзапросы в части from, которые материализуются во временные таблицы или что-то другое?

Я говорил о том, что таблицы tyres и wheels в реальной жизни TEMPORARY, поэтому MySQL не может их использовать дважды в одном запросе (Can't reopen). Я пытаюсь решить этот вопрос созданием двух временных таблиц из tyres2 =  select from tyres order by price limit X и wheels2 = select from wheels order by price limit X.

Про сортировку («front и rear тоже использовать в подзапросах») я выше не написал, что так и сделал. +))

vasya написал:

Да, иначе не получиться, а есть возможность в исходных TEMPORARY tyres сделать подходящий индекс для сортировки?

Да, конечно, учитывая, что таблицы создаются отдельным запросом. А какой индекс будет правильным для сортировки?

vasya написал:

В принципе также.
При прочих равных запрос с подзапросом будет чуть быстрее, чем 2 запроса с явным созданием временной таблицы. Например, нет добавочных расходов на анализ и выполнение лишнего запроса.

Я попробовал. У меня MySQL на тестах показал увеличение скорости на треть минимум. Сейчас попробую переписать скрипт так, чтобы все временные таблицы создавались в подзапросах одного большого запроса и поглядим. +)

Александр Трофимов написал:

Я попробовал. У меня MySQL на тестах показал увеличение скорости на треть минимум. Сейчас попробую переписать скрипт так, чтобы все временные таблицы создавались в подзапросах одного большого запроса и поглядим. +)

А какая у вас версия MySQL?

И так результаты опытов. Время генерации страниц по три на каждый вариант.

Как было: 2.22763 sec | 1.17455 sec | 1.85758 sec
Один общий запрос: 0.69147 sec | 1.00500 sec | 0.98592 sec
Две временные таблицы: 0.84656 sec | 0.93798 sec | 1.02652 sec

Повторные генерации страниц много быстрее, наверняка из-за кеша.

И так, было явно плохо. +)) Один общий запрос в среднем вроде бы чуть быстрее работает, чем две временные таблицы. Допускаю, что из-за дополнительных ресурсов на отправку и оформление запросов. Так как скрипт работает на php, думаю, каждый запрос тратит время на общение php с mysql. Надо будет посмотреть в сторону множественных запросов из php.

Нет слов, одни слюни! +))) Я скрестил общий запрос с идеей временных таблиц (Один общий запрос + Две временные таблицы), т.е. получил один большой общий запрос с повторяющимися подзапросами. И скорость повысилась еще в двое. Выставлю здесь запрос, может кто увидит еще возможность улучшения в плане построения запроса. +)))

ЗЫ. Здесь видимо есть ограничение на длину сообщения. Мой запрос не прошел. +)) Кому интересно, см. в приложении.

Отредактированно Александр Трофимов (25.03.2015 01:04:10)

---

Прикрепленные файлы:
Query.sql, Размер: 30,935 байт, Скачано: 1,585

я так понимаю для ORDER BY (column1+column2) DESC нельзя назначить индекс.
как же тогда оптимизировать такую сортировку?