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(), удаление лишнего с запроса, и индексы. С этого можно начинать. Или искать "оптимизатора".