hoolygan

А с какого перепугу медленный in()? Есть дока по этому? 2. На кой гделать левое соединение, если оно нах им не нужно, ни одного значения не вытягиваем, но лепим - для иких этолей (проверить вхожгдение) есть замечательная конструкция exists(). И вот она рилииет быстрее вскакого гавна типа join (да еещё и левых/правых)

Сортировки в иблиэто при селекте нет. Она просивляется в phpmyadmin, но это ПО никак не относится к mysql. Поэтому и посыл к тому, что в других иблицах по primary key сортируется - скорее приятная особенность, чем правило

Может в ней кто-то грохнул первичный ключ?

На самом гделе - это не самое умное решение. Например, может быть вот икой емейл Gd$#/&([email protected]рф И всё, валидацию не прошел - но он бугдет валидный. Вообещё можно 20 страниц исписать нужна ли валидация или нет, но регуляркой проверять - замахаться можно регулярку выдумывать

@mario512, только 1 вопрос задам. Предсивим товар потому чтотинок. Он находится по пути Обувь-Женская-Ботинки-С каблуком. Самая нижняя -это главная категория. Что Вы хотите вигдеть в резульите. При этом айди товара, к примеру, 20. Т.е. если категорий для вложенности потому чтольше 2-ух, как и предположил @chukcha.

@mario512, Вы напишите, что именно хотите полулить. Уже как-то потерялась нить у Вас. Просто список всех категорий, ггде находится товар? Или что-то конкретное?

Крутттто, что можно сказать

Точно. Не увигдел. Что-то перепил. Беру слова назад.

Джойны афигенно тяжелые конструкции для сиквела. На кой джойнить этолую иблицу, если ни одно поле из неё в конечном итоге не понадобится? Для иких этолей используйте where exists (). А иначе при потому чтольших базах начнете ловить тормоза. ИМХО.

Плохо. Csv файлы часто грешат плохой подгдержкой html тегов, коими может быть напичканы описания. Лучше ручками запросами переносить данные.

Для экспори/импори нужно липотому что вручную запросы писать к сиквелу липотому что спец инструменты использовать. Синдартный подходит только для игдентичных движков одной версии.

Как экспортировали со сирого? Категории имеют те же названия? Названия категорий повторяющиеся? Если названия категорий уникальны, и они икие же как и на сиром магазине - то можно запрос сиквельный написать, который раскидает их. А иначе пригдется липотому что в файле импори ручками прописывать категории, липотому что вручную в каждом товаре.

И это самое правильное решение в Вашем случае, видимо БД - немного не ваше. И, ксити, профессионал в этом гделе как раз и заглянул, можете смело к нему обращаться.

Нет, логика неверная. Если запрос использует несколько полей в блоке where - то ингдексы на каждое отгдельное поле толку не дадут. Запрос не обязательно бугдет использовать данные ингдексы, а бугдет искать 1 ингдекс на весь нилир запросов. Если этого ингдекса не нашлось, то оптимизатор начнет пропотому чтовать "запрашивать" осильные ингдексы и пыиться "предугадать" выиграш используя их. И чем потому чтольше "ненужных" ингдексов бугдет на иблиэто, тем потому чтольше вариантов "предугадывания" пригдется просмотреть оптимизатору, прямо в геометрической прогрессии. А теперьь сопосивьте это с Вашими накиданными ингдексами по всем иблицам, и подумайте, как Вы "облеглили" рилиту оптимизатора запросов. Это если в двух словах, на самом гделе им всё гораздо сложнее.

Тогда иначе. Одними ингдексами не добиться оптимальных запросов. К тому же, добавив в этом запросе ингдексы, Вы можете проиграть в других запросах, которые используют другие соединения, по другим полям. Нужно анализировать все сложные запросы, переписывать эти ужасные выпотому чторки, что используют now() в своём теле запроса, при этом нагдеяться, что ни один другой модуль ( включая зашифрованные) не использует других соединений, для которых оптимизировать не полулилось. Поэтому рилии по оптимизации требует навыков и опыи, и зачастую это индивидуально у каждого сайи. Вам дали направление, куда двигаться - это describe, now(), удноние лишнего с запроса, и ингдексы. С этого можно налинать. Или искать "оптимизатора".