Форум MySQL

Там не с индексами проблема, а в то, что у вас таблица ненормализована, если это намерно - ОК, но такая неромализованная таблица, как правило, имеет большой объем, что может быть плохо, особенно в случае многотабличных запросов (как правило, ненормализованные таблицы держат только для однотабличных запросов и ни для чего более). Индексов для такого количества столбцов можно вводить много и самых разнообразных.

Когда такой объем данных, поступают вообще очень жестко, вводят таблицу из двух столбцов, которую обвешивают кучей других таблиц, в которых хранят все остальные данны

`em_produce_id` int(10) unsigned NOT NULL auto_increment,   `em_produce_parent` int(10) unsigned NOT NULL default '0',

Эта хребтовая таблица - будет очень маленькой и по ней будет осуществляться поиск очень быстро, через неё будет удобно связывать другие таблицы. А еще если товар добавляется не часто, то и вообще эту таблицу забрасывают в оперативную память (таблица типа MEMORY). Индексы - это хорошо, но это не единственный и не всегда самый эффективный вариант оптимизации базы данных

а не могли бы Вы посмотреть дампы таблиц дампы и самый первый блок пхп кода с запросом, все ли там верно по индексам?

Когда как, если многотабличный запрос использует индексы, убирается в оперативной памяти (т.е. у сервера досточно ресурсов и он соответствующим образом настроен), то многотабличный запрос может выполняться быстрее множества однотабличных. Нередко бывает и наоборот - исследовать нужно в каждом конкретном случае.

т.е. без присоединения таблиц, запросы выполняются в оперативке и намного быстрей все это так? а если присоединяем, то увы жесткий диск гораздо медленней работает и поэтому дольше так?

В my.ini. У вас многотабличный запрос, все эти объединения порождают промежуточные таблицы - если они убираются, они обрабатываются в оперативной памяти, если не убираются - сбрасываются на жесткий диск, где обработка идет медленнее.

это как я понял в пхп настраивается? и значение в мегабайтах?
а что за промежуточная таблица то? ведь em_produce_stat_overal находится в основной таблице

Какое значение у параметра/директивы sort_buffer_size? Скорее всего у вас промежуточная таблица на жесткий диск сбрасывается... Увеличение этого параметра может ускорить запрос.

PS Вообще факторов довольно много, особенно в многотабличном запросе, да промежуточная таблица может занимать значительный объем.

ясно, буду пробовать, но хотел бы еще спросить, вот у меня идет

ORDER BY g.`em_package_weight` DESC, e.`em_produce_stat_overal` DESC

без указания

e.`em_produce_stat_overal` DESC

запрос выполняется до 300 мс, а с ним почти секунду....поначалу я подумал, что это из за присоединения, так долго и тогда я создал такое же поле в главной таблице из которой идет основная выборка и получил такое

ORDER BY g.`em_package_weight` DESC, a.`em_produce_stat_overal` DESC

но результат остался таким же, почти секунда :( записей в таблице 26 000, вот я и думаю, что все из-за большого объема, обойти никак нельзя? но сортировка по em_produce_stat_overal мне очень нужна, как быть?

П.С. убрать из запроса

a.`em_produce_stat_overal` DESC

и потом на пхп произвести сортировку как по мне нельзя, т.к. неверно отсортирует - сортировать должно из всей выборки, а не из 0,10 по лимиту.

Я боюсь при таком объеме нужно экспериментировать, аналитически тут уже сложно что-то сказать.

что можете сказать по этому поводу?