- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Понятно, зачем. Чтобы id попал в объект, который формируется в результате запроса.
Это было бы логично если бы был WHERE id IN (...), но в данном случае действительно лишнее
Выяснил что на генерацию 1 страницы приходится 1150 запросов. типа SELECT.
Какой-нибудь плагин типа конструктора страниц может такое выдать, например.
Это было бы логично если бы был WHERE id IN (...), но в данном случае действительно лишнее
И что это меняет? В любом случае нам нужен id, чтобы по нему сделать фильтр записей.
Это было бы логично если бы был WHERE id IN (...), но в данном случае действительно лишнее
В данном случае мы не знаем, что дальше происходит с объектом. Может быть лишнее, а может быть и нет. Возможно, он используется в нескольких местах - и что, откуда мы узнаем, к какому id он относится?
Среднестатистический интернет магазин на WP+WC.
Я понимаю, что описание товара + категории + характеристики + еще куча говна прицепом = много запросов в БД.
Но не 1К запросов... это даже для инет магазина слишком много.
Такое можно было бы понять, если на странице собирается шаблон с выдачей кучи товара.
Да и то, в подобном случае лучше как-то иначе обыграть подобную страницу или отказаться от неё, чем валить мускул подобной херней.
Ну я уже где то 14 лет пишу код за который мне деньги платят, да не 18 конечно, но до этого я писал код (довольно долго) за который мне не платили денег =))) и да водку (самогон) я пил уже примерно 25 лет назад =))
Но в вашем случае проще переписать на самом деле, так сказать провести рефакторинг и запилить... кстати а что там за CMS из 2006? php nuke какой нибудь? Я уже и CMS то не помню какие были в те года, тогда еще яндекс perl разработчиков нанимал, а я кстати на нем писал =)))
Самопал. Обошлась примерно в 500 000р. Мы тогда с женой, ну на пару лет раньше, четырехкомнатную квартиру купили за 1,500,000. В Москве. В хорошем районе 5 мин от метро на половине линии.
Так что переписать - я туп для этого, а с продажами сейчас куда хуже, то исть денег нет.
В данном случае мы не знаем, что дальше происходит с объектом. Может быть лишнее, а может быть и нет. Возможно, он используется в нескольких местах - и что, откуда мы узнаем, к какому id он относится?
Да, я тоже так и подумал.
И что это меняет? В любом случае нам нужен id, чтобы по нему сделать фильтр записей.
Зачем? Необязательно выбирать поле в select чтобы по нему сделать фильтрацию.
Запрос вида
вернет только строки где id = 1 следовательно в select id не нужен так как он уже известен, других там не будет и это лишние данные которые гоняются, он нужен только в IN чтобы понять к какому id из запрошенных какой parent_id соответствует
вернет только строки где id = 1 следовательно в select id не нужен так как он уже известен, других там не будет и это лишние данные которые гоняются, он нужен только в IN чтобы понять к какому id из запрошенных какой parent_id соответствует
Да, все верно, технически добавление этого поля в запрос не имеет смысла, так как id уже известен. Возможно как то используется при выводе полученных данных, а возможно и просто так добавили, не подумав.