kuvand Опубликовано 27 января, 2014 Жалоба Поделиться Опубликовано 27 января, 2014 Только перенес сайт на simpla 2.2.4 (ранее был на самописе) И на хостинг ukraine.com.ua. товаров на сайте 4500.Хостер жалуется что много медленных запросов, и перерасходуем выделенное время процессора на обработку запросов Вот например запрос " SELECT id FROM s_products p, s_products_categories pc WHERE pc.product_id=p.id AND p.position>'0' AND pc.POSITION=(SELECT MIN(pc2.POSITION) FROM s_products_categories pc2 WHEREpc.product_id=pc2.product_id) AND pc.category_id='398' AND p.visible ORDER BY p.POSITION LIMIT 1" Пишет что для обработки сканировано 75333780 рядков и заняло это все 00:00:40 времени, скажите пж что делать с этим, есть ли готовые решения оптимизации , и нормально и это.Еще вопрос, используются ли индексы в базе данных (слышал что это может помочь) Заранее спасибо. Цитата Ссылка на сообщение Поделиться на другие сайты
osben Опубликовано 27 января, 2014 Жалоба Поделиться Опубликовано 27 января, 2014 Это по все видимости баг, если не ошибаюсь то ето вызов следующего товара. И почему то позиция текущего 0. Проверьте в s_products колонку position. Цитата Ссылка на сообщение Поделиться на другие сайты
kuvand Опубликовано 27 января, 2014 Автор Жалоба Поделиться Опубликовано 27 января, 2014 Это по все видимости баг, если не ошибаюсь то ето вызов следующего товара. И почему то позиция текущего 0. Проверьте в s_products колонку position. а что в этой колонке проверять? Я при переносе в position ставил "0" Цитата Ссылка на сообщение Поделиться на другие сайты
osben Опубликовано 27 января, 2014 Жалоба Поделиться Опубликовано 27 января, 2014 Сделайте UPDATE s_products SET position=id Цитата Ссылка на сообщение Поделиться на другие сайты
kuvand Опубликовано 27 января, 2014 Автор Жалоба Поделиться Опубликовано 27 января, 2014 Сделайте UPDATE s_products SET position=idТак и сделал но нагрузка особо не изменилась Цитата Ссылка на сообщение Поделиться на другие сайты
osben Опубликовано 27 января, 2014 Жалоба Поделиться Опубликовано 27 января, 2014 Так и сделал но нагрузка особо не изменилась Проверьте теперь свой запрос. Либо покажите больше примеров с медленными запросами, может где еще были допущены ошибки при переносе. Цитата Ссылка на сообщение Поделиться на другие сайты
kuvand Опубликовано 27 января, 2014 Автор Жалоба Поделиться Опубликовано 27 января, 2014 Они такие , все однотипные , только циферки меняются SELECT id FROM s_products p, s_products_categories pc WHERE pc.product_id=p.id AND p.position<'4828' AND pc.POSITION=(SELECT MIN(pc2.POSITION) FROM s_products_categories pc2 WHEREpc.product_id=pc2.product_id) AND pc.category_id='401' AND p.visible ORDER BY p.POSITION DESC LIMIT 1 SELECT id FROM s_products p, s_products_categories pc WHERE pc.product_id=p.id AND p.position<'3968' AND pc.POSITION=(SELECT MIN(pc2.POSITION) FROM s_products_categories pc2 WHEREpc.product_id=pc2.product_id) AND pc.category_id='147' AND p.visible ORDER BY p.POSITION DESC LIMIT 1 SELECT id FROM s_products p, s_products_categories pc WHERE pc.product_id=p.id AND p.position<'3964' AND pc.POSITION=(SELECT MIN(pc2.POSITION) FROM s_products_categories pc2 WHEREpc.product_id=pc2.product_id) AND pc.category_id='147' AND p.visible ORDER BY p.POSITION DESC LIMIT 1 Цитата Ссылка на сообщение Поделиться на другие сайты
kuvand Опубликовано 27 января, 2014 Автор Жалоба Поделиться Опубликовано 27 января, 2014 Думаю если индексы создать будет быстрее? Цитата Ссылка на сообщение Поделиться на другие сайты
osben Опубликовано 27 января, 2014 Жалоба Поделиться Опубликовано 27 января, 2014 Думаю если индексы создать будет быстрее? Сколько записей в s_products, s_products_categories и s_categories?И скажите Вы на сайте использую те функционал следующего и предыдущего товара ? Цитата Ссылка на сообщение Поделиться на другие сайты
kuvand Опубликовано 28 января, 2014 Автор Жалоба Поделиться Опубликовано 28 января, 2014 Сколько записей в s_products, s_products_categories и s_categories?И скажите Вы на сайте использую те функционал следующего и предыдущего товара ?s_products, 4360s_products_categories 8600 (здесь в position тоже везде 0)s_categories 472 На сайте есть но думаю им можно пожертвовать Цитата Ссылка на сообщение Поделиться на другие сайты
Kosjak76 Опубликовано 28 января, 2014 Жалоба Поделиться Опубликовано 28 января, 2014 Сделайте везде в этих таблицах SET position=idХотя в категориях наверное можно не делать, а в s_products_categories нужно Цитата Ссылка на сообщение Поделиться на другие сайты
osben Опубликовано 28 января, 2014 Жалоба Поделиться Опубликовано 28 января, 2014 s_products, 4360s_products_categories 8600 (здесь в position тоже везде 0)s_categories 472 На сайте есть но думаю им можно пожертвоватьПопробуйте проставить position в s_products_categories. В зависимости от позиции определяется основная категория товара Конечно и категорий многовато... Это тоже может быть частичной проблемой. Так как все записи постоянно выбираются и создаётся дерево категорий. Цитата Ссылка на сообщение Поделиться на другие сайты
osben Опубликовано 28 января, 2014 Жалоба Поделиться Опубликовано 28 января, 2014 Сделайте везде в этих таблицах SET position=id Для начало в s_products_categories нету id . Цитата Ссылка на сообщение Поделиться на другие сайты
Kosjak76 Опубликовано 28 января, 2014 Жалоба Поделиться Опубликовано 28 января, 2014 Сорри, я с планшета... Имел в ввиду id товара. Цитата Ссылка на сообщение Поделиться на другие сайты
osben Опубликовано 28 января, 2014 Жалоба Поделиться Опубликовано 28 января, 2014 Сорри, я с планшета... Имел в ввиду id товара.Тоже не катит, так как товар у нас не уникальный, и того может выйти что таже беда. лучше уже UPDATE s_products_categories SET position = category_id (мое мнение) Цитата Ссылка на сообщение Поделиться на другие сайты
osben Опубликовано 28 января, 2014 Жалоба Поделиться Опубликовано 28 января, 2014 Ну все, началось... я бы сам движок перепилил, надо глобальную оптимизацию всего, включая css да и вообще давай те класс кеширование навесим, и не просто так что бы и мемкеш, sqlite, хкеш и т.д. Давай те сначала человек приведет БД в то состояние как оно должно быть изначально. А потом уже смотреть действительно ли это запросы медленные. Цитата Ссылка на сообщение Поделиться на другие сайты
Kosjak76 Опубликовано 28 января, 2014 Жалоба Поделиться Опубликовано 28 января, 2014 Это врядли, в таком случае получим в одной категории у ВСЕХ товаров ОДИНАКОВУЮ позицию, с чем и боролись...Мне мой вариант нравится больше Цитата Ссылка на сообщение Поделиться на другие сайты
osben Опубликовано 28 января, 2014 Жалоба Поделиться Опубликовано 28 января, 2014 А давай не твои и не мой, а просуммируем product_id и category_id ? Цитата Ссылка на сообщение Поделиться на другие сайты
Kosjak76 Опубликовано 28 января, 2014 Жалоба Поделиться Опубликовано 28 января, 2014 Шикарный вариант, я ЗА Хотя тоже будет не уникально... Цитата Ссылка на сообщение Поделиться на другие сайты
kuvand Опубликовано 28 января, 2014 Автор Жалоба Поделиться Опубликовано 28 января, 2014 1 s_products_categories сделал position по products_idРазницы не заметил 2 C EXPLAIN обработался очень быстро Showing rows 0 - 0 (3 total, Запрос занял 0.0008 сек.)3 я скопировал базу кто хочет глянуть, я сброшу доступ Цитата Ссылка на сообщение Поделиться на другие сайты
kuvand Опубликовано 28 января, 2014 Автор Жалоба Поделиться Опубликовано 28 января, 2014 Для облегчения работы скопировал в отдельную базу проблемные таблицыкто может взглянуть говорите дам доступ Цитата Ссылка на сообщение Поделиться на другие сайты
kuvand Опубликовано 28 января, 2014 Автор Жалоба Поделиться Опубликовано 28 января, 2014 Совсем непонятно, почему эти запросы становятся у Вас тяжелыми. Они довольно просты и безобидны. Пробуйте EXPLAIN (приписать в запросу слева и посмотреть, что даст). Встречался с ситуацией, когда автомат у хостера классифицировал простенькие запросы как тяжелые (потом оказалось, что статистика у них шла СРАЗУ на много пользователей, и причина была в реально тяжелых запросах ДРУГИХ пользователей хостинга). Что касается следующего-предыдущего товара, то имеет смысл этот момент переработать с целью оптимизации:http://forum.simplacms.ru/topic/5360-соседние-продукты-нерационально-до-крайности/Я за комментировал в ProductView вызов функций et_prev_product и get_next_product.Вроде бы как страницы начали быстрее грузится Хотя хотелось бы конечно именно запросы ускорить а не убиватьфункционал Цитата Ссылка на сообщение Поделиться на другие сайты
osben Опубликовано 28 января, 2014 Жалоба Поделиться Опубликовано 28 января, 2014 кинь мне в личку, гляну на досуге. Может чем то помогу Цитата Ссылка на сообщение Поделиться на другие сайты
kuvand Опубликовано 28 января, 2014 Автор Жалоба Поделиться Опубликовано 28 января, 2014 Всем спасибо за участие. Проблема решена товарищем osben))За что ему особая Благодарность. Цитата Ссылка на сообщение Поделиться на другие сайты
kuvand Опубликовано 28 января, 2014 Автор Жалоба Поделиться Опубликовано 28 января, 2014 Посмотрел на присланной базе приведенные запросы.Через EXPLAIN видно, что при этих запросах затрагивается примерно полсотни строк. Неоткуда там взяться десяткам миллионов, о которых Вы писали. Думаю, Ваши хостеры что-то напутали. Требуйте у них ТОЧНЫХ объяснений на одном КОНКРЕТНОМ примере.. Не знаю насчет тех цифр, но проблема была решена Насколько я понял Виной бил мой перенос При Я заново создавал s_products_categories и насколько я понял не проставил ключи или что В общем после выполнения запросов проблема решиласьЗапросы: ALTER TABLE `s_products_categories` ADD PRIMARY KEY (`product_id`,`category_id`);ALTER TABLE `s_products_categories` ADD INDEX ( `product_id` );ALTER TABLE `s_products_categories` ADD INDEX ( `category_id` );ALTER TABLE `s_products_categories` ADD INDEX ( `position` ); Цитата Ссылка на сообщение Поделиться на другие сайты
Рекомендуемые сообщения
Присоединяйтесь к обсуждению
Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.