Делаю эксперименты на локалке с базой товаров около 10000 и пытаюсь пояснить суть проблемы....
Выполняю твой запрос и получаю такую картинку
Всё печально... смотрим почему
видим Using temporary; Using filesort ...
Это говорит о том что две большие таблицы со всеми потрохами связываются, сохраняются во временной таблице, эта временная таблица сортируется и потом берётся 1000 записей.
На этапе формирования временной таблицы у тебя и вылазит ошибка. Отчасти ситуацию улучшит то о чем пишет rb2, временная таблица будет поменьше и на какое-то время ошибка исчезнет...
Но допустим нам нужны все поля...
Давай рассмотрим такой вариант:
Картинка совсем другая
Что-же сделано в этом запросе?
Наша задача: отсортировать товары по наименованию и получить тысячу.
Не трогая таблицу товаров сортируем наименования и извлекаем 1000 идентификаторов товаров....
А потом на полученные идентификаторы мы мягенько навешиваем все поля... таким образом мы избежали Using temporary; Using filesort и выдернули поля только нужных товаров.
Вот сравнение статусов этих запросов проясняющее что происходит при выполнении (первый запрос мой, второй - твой)
К этому запросу надо добавить рекомендации rb2... лишнее извлекать и гонять по сети, при твоём количестве товаров, слишком расточительно.
Я думаю проблема понятна и что делать тоже ясно...
Тебя ждут ещё некоторые неприятности...
Когда в запросе LIMIT 0, 1000 то всё красиво, а вот когда надо выбрать тысячу ближе к концу, например LIMIT 799000, 1000 - будет тоскливее.
Дело в том что алгоритм работы примерно такой: выдёргиваются 800000 записей и отбрасываются первые 799000.... тоскливо, но в любом случае вариант который я предложил будет гораздо быстрее твоего запроса.
Это вовсе не тупик и такие засады тоже решаются... но это совсем другая история и шаманить надо конкретно по ситуации...
Если всё буду рассказывать без куска хлеба останусь B)