|
Модераторы: skyboy |
|
maxipub |
|
||||||
Опытный Профиль Группа: Участник Сообщений: 517 Регистрация: 22.10.2009 Репутация: 1 Всего: 1 |
Добрый день.
Оптимизирую один код. Уже есть прогресс, но уперся в одном месте. Есть запрос на выборку товаров:
goods - таблица с товарами cats - разделы items - наличие (одна строка - одна товарная позиция, нужно хранить индивидуальную информацию по каждой из них) stock_list - список складов Суть в том, что производится выборка данных по товарам указанного раздела (c.disabled=0 AND c.cat_id=123), которые есть в наличии (i.order_id=0) со всех доступных складов (l.stock_id=i.stock_id AND l.stock_avaliable=1). Все это дело выполняется примерно 0,02 сек. Но дергается часто. Сам по себе подзапрос возвращает список всех товаров в наличии со всех доступных складов. Он нужен для связи по конкретной ревизии товара. Если подзапрос выполнить как самостоятельный запрос:
То, он выполняется за 0,0004 сек и возвращает около 2500 записей - список id. Но если сделать что-то вида:
То это тут же начинает выполнятся порядка 0,02 сек. Я так понимаю, именно подзапрос все дело тормозит. Индексы везде вылизаны, и используются. Само по себе подзапрос, как самостоятельный запрос, выполняется быстро, и выозвращает не много результатов. Но стоит поставить его в SELECT * FROM (-подзапрос-) AS t - как получаем эти пресловутые 0,02 сек... Добавлено через 9 минут и 24 секунды Если вдруг не очевидно для чего подзапрос - чтоб уменьшить пересечения при джойнах: goods - десятки тысяч записей cats - сотни items - сотни тысяч stock_list - десятки И после этого придется накладывать на все группировку по товару... |
||||||
|
|||||||
Akina |
|
|||
Советчик Профиль Группа: Модератор Сообщений: 20570 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 106 Всего: 453 |
Не... всё становится хуже. Уж лучше "куча пересечений", но зато можно использовать индексы. А так ты получаешь неиндексированный результат подзапроса, который далее фуллсканится. Да ещё, не приведи господи, результат материализуется... -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
maxipub |
|
|||
Опытный Профиль Группа: Участник Сообщений: 517 Регистрация: 22.10.2009 Репутация: 1 Всего: 1 |
Akina, MySQL 5.7.19, я слышал что начиная с 5.7 он умеет делать индексы для подзапросов, ошибся? EXPLAIN содержит какой-то auto_key0:
А в общем все оказалось верно. Убрал подзапрос, сейчас все выполняется не дольше 0,0015 сек. Конечно, хотелось бы еще ускорить, но понимаю что места для маневров уже не много. Пока сойдет и так, позже еще попробую вернуться к этому вопросу. В очередной раз большое спасибо! |
|||
|
||||
Akina |
|
|||
Советчик Профиль Группа: Модератор Сообщений: 20570 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 106 Всего: 453 |
Не ошибся... вот только кто сказал, что этот автосгенерённый ключ будет подходить для оптимизации запроса? Не вижу потенции для ускорения, кроме создания подходящих индексов. Сплошные INNER JOIN и отборы по одному значению - нет пространства для манёвра. -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | MySQL | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |