Перейти к содержанию

hoolygan

Пользователи
  • Публикаций

    786
  • Зарегистрирован

  • Посещение

Репутация

85 Очень хороший

Информация о hoolygan

  • Звание
    Продвинутый пользователь

Посетители профиля

1 997 просмотров профиля
  1. Сортировки в таблице при селекте нет. Она проставляется в phpmyadmin, но это ПО никак не относится к mysql. Поэтому и посыл к тому, что в других таблицах по primary key сортируется - скорее приятная особенность, чем правило
  2. Может в ней кто-то грохнул первичный ключ?
  3. На самом деле - это не самое умное решение. Например, может быть вот такой емейл Gd$#/&(gc45@rd.baraban.рф И всё, валидацию не прошел - но он будет валидный. Вообще можно 20 страниц исписать нужна ли валидация или нет, но регуляркой проверять - замахаться можно регулярку выдумывать
  4. hoolygan

    Запрос в MySQL

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

    Запрос в MySQL

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

    Запрос в MySQL

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

    Запрос в MySQL

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

    Запрос в MySQL

    Джойны афигенно тяжелые конструкции для сиквела. На кой джойнить целую таблицу, если ни одно поле из неё в конечном итоге не понадобится? Для таких целей используйте where exists (). А иначе при больших базах начнете ловить тормоза. ИМХО.
  9. Плохо. Csv файлы часто грешат плохой поддержкой html тегов, коими может быть напичканы описания. Лучше ручками запросами переносить данные.
  10. Для экспорта/импорта нужно либо вручную запросы писать к сиквелу либо спец инструменты использовать. Стандартный подходит только для идентичных движков одной версии.
  11. Как экспортировали со старого? Категории имеют те же названия? Названия категорий повторяющиеся? Если названия категорий уникальны, и они такие же как и на старом магазине - то можно запрос сиквельный написать, который раскидает их. А иначе придется либо в файле импорта ручками прописывать категории, либо вручную в каждом товаре.
  12. И это самое правильное решение в Вашем случае, видимо БД - немного не ваше. И, кстати, профессионал в этом деле как раз и заглянул, можете смело к нему обращаться.
  13. Нет, логика неверная. Если запрос использует несколько полей в блоке where - то индексы на каждое отдельное поле толку не дадут. Запрос не обязательно будет использовать данные индексы, а будет искать 1 индекс на весь набор запросов. Если этого индекса не нашлось, то оптимизатор начнет пробовать "запрашивать" остальные индексы и пытаться "предугадать" выиграш используя их. И чем больше "ненужных" индексов будет на таблице, тем больше вариантов "предугадывания" придется просмотреть оптимизатору, прямо в геометрической прогрессии. А теперь сопоставьте это с Вашими накиданными индексами по всем таблицам, и подумайте, как Вы "облегчили" работу оптимизатора запросов. Это если в двух словах, на самом деле там всё гораздо сложнее.
  14. Тогда иначе. Одними индексами не добиться оптимальных запросов. К тому же, добавив в этом запросе индексы, Вы можете проиграть в других запросах, которые используют другие соединения, по другим полям. Нужно анализировать все сложные запросы, переписывать эти ужасные выборки, что используют now() в своём теле запроса, при этом надеяться, что ни один другой модуль ( включая зашифрованные) не использует других соединений, для которых оптимизировать не получилось. Поэтому работа по оптимизации требует навыков и опыта, и зачастую это индивидуально у каждого сайта. Вам дали направление, куда двигаться - это describe, now(), удаление лишнего с запроса, и индексы. С этого можно начинать. Или искать "оптимизатора".
  15. Т.е. Вы занимались оптимизацией запросов в ms sql? Простите, но если так, должны понимать, каким образом запрос попадает в оптимизатор (сейчас про ms sql говорю), и что вначале оптимизатор анализирует FROM, дальше ON, потом JOIN, потом всё остальное. Могу предположить (не уверен, но чисто предположение), что тут точно так же. И к тому же NOW() вернет время с очень конкретной точностью, а значит запрос не будет закеширован. А также что индексы будут использоваться именно в том порядке, что прописаны в запросе, а также что составные индексы будут использоваться в определенных случаях более оптимально. И что самое главное- что нужно изучать план запроса. Тогда скажите, пожалуйста, как оптимизировать этот запрос, если Вы даже не посмотрели выполнение запроса, как посоветовали постом выше?
×

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.