|
Модераторы: skyboy |
|
maxipub |
|
|||
Опытный Профиль Группа: Участник Сообщений: 517 Регистрация: 22.10.2009 Репутация: 1 Всего: 1 |
Столкнулся с тупняком.
Выбираем из БД данные о юзерах, у которых есть посты, запрос вида:
Таблицы разраслись. Такой примитив начал выполняться по 0,1 сек. и выше. Зашел в профилирование, 99% - sending data, посмотрел на количество подходящих записей - вся проблема в сильном пересечении данных по ключу. Можно переделать проверку наличия записей INNER JOIN posts AS p ON p.user_id=u.user_id (нужна проверка в принципе их наличия, хоть 1, количество не важно, просто факт наличия, т.е. вида SELECT 1 FROM...) чтоб в запросе не джойнилась за зря таблица. В подзапрос или еще как-то? Мне кажется, это возможно. А как сделать - не соображу. |
|||
|
||||
Akina |
|
||||
Советчик Профиль Группа: Модератор Сообщений: 20570 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 106 Всего: 453 |
maxipub, перепишите вопрос поаккуратнее. Чтобы "запрос вида" имел хоть какой-то смысл. Чтобы профилирование было цитатой, а не сочинением по мотивам. Структуру хранения покажите, статистику соответствия (или хотя бы план запроса). Потому что сейчас ничего, кроме запроса типа
-------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
||||
|
|||||
maxipub |
|
||||
Опытный Профиль Группа: Участник Сообщений: 517 Регистрация: 22.10.2009 Репутация: 1 Всего: 1 |
Akina, там большой запрос и широкая структура, я пришел в упрощению такого вида, и понял что оно тормозит. Ок, если принципиально, постараюсь подготовить данные.
EXISTS выполняется 0.09 - 0.12 сек. От второго варианта ожидал хорошего результата, но получилось вообще непойми что. Запрос с ним выполняется 0.05 сек. - все равно жутко долго для такого запроса. Но дело даже не в этом. Сам:
Выполняется 0.15 сек. А весь запрос:
За 0.05 сек. Как такое вообще возможно? Кеширование отключено. |
||||
|
|||||
Akina |
|
|||
Советчик Профиль Группа: Модератор Сообщений: 20570 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 106 Всего: 453 |
Не видя плана выполнения запросов, гадать можно сколько угодно. -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
maxipub |
|
||||||
Опытный Профиль Группа: Участник Сообщений: 517 Регистрация: 22.10.2009 Репутация: 1 Всего: 1 |
Ок, думал так получится. Просто не люблю вываливать кучу данных, "а вы разбирайтесь как хотите". Обычно описываю на схожем примере, мне подсказывают, и далее уже реализацию доделываю сам.
Ок, раз надо, ловите:
таблицы:
текущий запрос:
первая таблица - категории сайта вторая - товары сайта третья - товарные позиции (наличие) задача - получить список товаров, которые: 1) находятся не в отключенных разделах (c.store_cat_disabled=0) и не в разделах для подарков (c.store_cat_is_gifts) 2) в наличии (по ним i.real_goods_id=g.store_goods_total_parent_id есть позиции, которые не в заказах cart_id=0) как-то так... |
||||||
|
|||||||
Akina |
|
||||
Советчик Профиль Группа: Модератор Сообщений: 20570 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 106 Всего: 453 |
Из очевидного:
Из менее очевидного:
А так больше ничего в голову не приходит... -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
||||
|
|||||
maxipub |
|
|||
Опытный Профиль Группа: Участник Сообщений: 517 Регистрация: 22.10.2009 Репутация: 1 Всего: 1 |
Akina, спасибо за идеи.
Индекс на категории при запросе игнорируется, пытался навязать его принудительно - время выполнения запроса выросло вполовину. Неочевидный индекс на позиции немного помог, время выполнения запроса сократилось примерно вдвое. В итоге с Вашей помощью сейчас имеем в пределах 0.03-0.04 сек. на продакшине. Неплохо, но хотелось бы лучшего результата. Буду искать еще варианты, если что получится - отпишусь. Кстати, если убрать сортировку, скорость возрастает еще в 4-5 раз. Первым делом попробую копать в эту сторону. |
|||
|
||||
_zorn_ |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1077 Регистрация: 21.8.2007 Репутация: 2 Всего: 12 |
EXPLAIN перед SELECT посмотри что не так в твоих запросах.
Это сообщение отредактировал(а) _zorn_ - 14.5.2018, 16:07 |
|||
|
||||
maxipub |
|
|||
Опытный Профиль Группа: Участник Сообщений: 517 Регистрация: 22.10.2009 Репутация: 1 Всего: 1 |
_zorn_, двумя постами выше есть EXPLAIN. И что не так в моих запросах?
|
|||
|
||||
maxipub |
|
|||
Опытный Профиль Группа: Участник Сообщений: 517 Регистрация: 22.10.2009 Репутация: 1 Всего: 1 |
Есть новости. Вынес пару не критичных полей за пределы таблицы items, получил почти двукратный прирост производительности. Пусть не то ускорение, которого хочу. Пусть экстенсивный путь. Но кое-какой результат.
|
|||
|
||||
_zorn_ |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1077 Регистрация: 21.8.2007 Репутация: 2 Всего: 12 |
Я имел ввиду что это ГЛАВНЫЙ инструмент. Например "Using where; Using temporary; Using filesort" ЭТО ОЧЕНЬ ПЛОХО. Как минимум "filesort". Из информации которую дает EXPLAIN вы должны почерпнуть ЧТО НЕ ТАК в вашем запросе и где можно ключей наворотить, а где запрос упростить. Главное не смотреть на эту инфу как баран на новые ворота. Там в принципе понятно же все. ЗЫ. filesort обычно когда нет нужных индексов. Это сообщение отредактировал(а) _zorn_ - 28.5.2018, 15:22 |
|||
|
||||
Akina |
|
|||
Советчик Профиль Группа: Модератор Сообщений: 20570 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 106 Всего: 453 |
Ну не надо так категорично-то... а то тут недавно наблюдал, как товарищ интенсивно боролся с filesort - и всё удивлялся, что как только поборет, так почему-то дольше получается... ага... пока ему не сказали, что бороться с filesort-ом ТРЁХ записей как минимум неразумно. -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
maxipub |
|
|||
Опытный Профиль Группа: Участник Сообщений: 517 Регистрация: 22.10.2009 Репутация: 1 Всего: 1 |
||||
|
||||
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | MySQL | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |