Перейти к содержанию
Официальный форум поддержки Simpla

Медленные запросы


Рекомендуемые сообщения

Только перенес сайт на 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  времени,  скажите пж  что делать с этим,  есть ли готовые решения оптимизации , и нормально и это.

Еще  вопрос, используются ли индексы  в  базе данных (слышал что это может помочь) 

Заранее спасибо.

Ссылка на сообщение
Поделиться на другие сайты
Это по все видимости баг, если не ошибаюсь то ето вызов следующего товара. И почему то позиция текущего 0. 
 
Проверьте в s_products колонку position. 
 
Ссылка на сообщение
Поделиться на другие сайты

 

Это по все видимости баг, если не ошибаюсь то ето вызов следующего товара. И почему то позиция текущего 0. 
 
Проверьте в s_products колонку position. 

 

а что в этой колонке проверять?  

Я при переносе  в position ставил  "0" 

Ссылка на сообщение
Поделиться на другие сайты

Так  и сделал но нагрузка особо не изменилась 

Проверьте теперь свой запрос. Либо покажите больше примеров с медленными запросами, может где еще были допущены ошибки при переносе. 

Ссылка на сообщение
Поделиться на другие сайты

Они такие , все однотипные , только  циферки меняются 

 

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

Ссылка на сообщение
Поделиться на другие сайты

Думаю если индексы создать  будет быстрее? 

Сколько записей в s_products, s_products_categories и s_categories?

И скажите Вы на сайте использую те функционал  следующего и предыдущего товара ?

Ссылка на сообщение
Поделиться на другие сайты

Сколько записей в s_products, s_products_categories и s_categories?

И скажите Вы на сайте использую те функционал  следующего и предыдущего товара ?

s_products,  4360

s_products_categories  8600    (здесь в position тоже везде 0)

s_categories  472 

На сайте есть но думаю им можно пожертвовать

Ссылка на сообщение
Поделиться на другие сайты

Сделайте везде в этих таблицах SET position=id

Хотя в категориях наверное можно не делать, а в s_products_categories нужно

Ссылка на сообщение
Поделиться на другие сайты

s_products,  4360

s_products_categories  8600    (здесь в position тоже везде 0)

s_categories  472 

На сайте есть но думаю им можно пожертвовать

Попробуйте проставить position в s_products_categories. В зависимости от позиции определяется основная категория товара 

 

Конечно и категорий многовато... Это тоже может быть частичной проблемой. Так как все записи постоянно выбираются и создаётся дерево категорий.  

Ссылка на сообщение
Поделиться на другие сайты

Сорри, я с планшета... Имел в ввиду id товара.

Тоже не катит, так как товар у нас не уникальный, и того может выйти что таже беда. лучше уже UPDATE s_products_categories SET position = category_id (мое мнение) 

Ссылка на сообщение
Поделиться на другие сайты

Ну все, началось... я бы сам движок перепилил, надо глобальную оптимизацию всего, включая css :lol:  да и вообще давай те класс кеширование навесим, и не просто так что бы и мемкеш,  sqlite, хкеш и т.д. 
:D 

Давай те сначала человек приведет БД в то состояние как оно должно быть изначально. А потом уже смотреть действительно ли это запросы медленные. 

Ссылка на сообщение
Поделиться на другие сайты

Это врядли, в таком случае получим в одной категории у ВСЕХ товаров ОДИНАКОВУЮ позицию, с чем и боролись...

Мне мой вариант нравится больше :)

Ссылка на сообщение
Поделиться на другие сайты

post-17277-0-13973800-1390897380_thumb.pngs_products_categories  сделал position  по products_id

Разницы не заметил

 

2    C EXPLAIN обработался очень быстро     Showing rows 0 - 0 (3 total, Запрос занял 0.0008 сек.)

3 я скопировал базу кто хочет глянуть, я  сброшу доступ

Ссылка на сообщение
Поделиться на другие сайты

Для  облегчения  работы скопировал в отдельную базу проблемные таблицы

кто может взглянуть говорите   дам доступ 

Ссылка на сообщение
Поделиться на другие сайты

Совсем непонятно, почему эти запросы становятся у Вас тяжелыми. Они довольно просты и безобидны. Пробуйте EXPLAIN (приписать в запросу слева и посмотреть, что даст). Встречался с ситуацией, когда автомат у хостера классифицировал простенькие запросы как тяжелые (потом оказалось, что статистика у них шла СРАЗУ на много пользователей, и причина была в реально тяжелых запросах ДРУГИХ пользователей хостинга).

 

Что касается следующего-предыдущего товара, то имеет смысл этот момент переработать с целью оптимизации:

http://forum.simplacms.ru/topic/5360-соседние-продукты-нерационально-до-крайности/

Я  за комментировал в ProductView  вызов функций et_prev_product  и  get_next_product.

Вроде бы как страницы начали быстрее  грузится 

Хотя хотелось бы  конечно именно запросы ускорить  а не убиватьфункционал

Ссылка на сообщение
Поделиться на другие сайты

Посмотрел на присланной базе приведенные запросы.

Через 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` );
Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

Загрузка...
×
×
  • Создать...