оптимизация запроса / MySQL

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

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

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / MySQL [игнор отключен] [закрыт для гостей] / оптимизация запроса

13 сообщений из 13, страница 1 из 1

оптимизация запроса

#33270055

Dima S

Гость

Есть два практически одинаковых запроса.

первый:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

SELECT purchase.*
FROM ((((consultant 
RIGHT JOIN (((((purchase
LEFT JOIN credit_operation ON purchase.credit_operation_guid = credit_operation.credit_operation_guid)
LEFT JOIN payment ON purchase.payment_guid = payment.payment_guid)
LEFT JOIN personal_credit ON purchase.personal_credit_guid = personal_credit.personal_credit_guid) 
INNER JOIN status_name ON purchase.rec_status = status_name.logical) 
INNER JOIN passport ON purchase.purchaser = passport.owner_guid) ON consultant.consultant_guid = purchase.purchaser) 
LEFT JOIN passport AS passport_1 ON consultant.sponsor = passport_1.owner_guid)   
LEFT JOIN doc_author ON purchase.purchase_guid = doc_author.doc_guid) 
LEFT JOIN credit_line ON credit_operation.credit_line = credit_line.credit_line_guid  and credit_line.credit_type_id= 2 )
WHERE status_name.is_visible= 1   
order by  purchase.rec_created  LIMIT  100

второй:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

SELECT purchase.*
FROM ((((consultant 
RIGHT JOIN (((((purchase
LEFT JOIN credit_operation ON purchase.credit_operation_guid = credit_operation.credit_operation_guid)
LEFT JOIN payment ON purchase.payment_guid = payment.payment_guid)
LEFT JOIN personal_credit ON purchase.personal_credit_guid = personal_credit.personal_credit_guid) 
INNER JOIN status_name ON purchase.rec_status = status_name.logical) 
INNER JOIN passport ON purchase.purchaser = passport.owner_guid) ON consultant.consultant_guid = purchase.purchaser) 
LEFT JOIN passport AS passport_1 ON consultant.sponsor = passport_1.owner_guid)   
LEFT JOIN doc_author ON purchase.purchase_guid = doc_author.doc_guid) 
LEFT JOIN credit_line ON credit_operation.credit_line = credit_line.credit_line_guid)
WHERE status_name.is_visible= 1   and credit_line.credit_type_id= 2 
order by  purchase.rec_created  LIMIT  100

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

Код: plaintext

credit_line.credit_type_id= 2

в первом случае - внутри LEFT JOIN, во втором - в конце запроса.

первый запрос выполняется "влет", второй - тормозит жутко.

вопрос: почему так происходит?

если запросы формируются динамически и сейчас есть только возможность ставить условия в конец запроса, то можно как-то указывать оптимизатору, во втором случае, так не тормозить?

...

Рейтинг:

0 / 0

14.09.2005, 22:10:31

| Ответить | Цитировать | Написать

оптимизация запроса

#33270081

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

Хинт: смотрите план запроса через EXPLAIN запрос.
Кроме того, мне кажется, очевидно, что если сначала отделить 1% от 1000 и умножить получившихся 10 записей на ещё 1000 из другой таблицы выйдет быстрее, чем если умножить 1000 записей одной на 1000 записей другой и потом отделить 0,001% от получившегося.

...

Рейтинг:

0 / 0

14.09.2005, 22:55:17

| Ответить | Цитировать | Написать

оптимизация запроса

#33270099

Dima S

Гость

DocAlКроме того, мне кажется, очевидно, что если сначала отделить 1% от 1000 и умножить получившихся 10 записей на ещё 1000 из другой таблицы выйдет быстрее, чем если умножить 1000 записей одной на 1000 записей другой и потом отделить 0,001% от получившегося.
Да, очевидно.
Но почему, при выполнении джойнов, mysql не смотрит на все условия, которые есть в запросе для таблиц, учавствующих в джойне? По идее, оптимизатор должен сам сообразить (для нас, во втором случае) отсекать лишние записи во время обьединения, а не после. Нет?

...

Рейтинг:

0 / 0

14.09.2005, 23:22:53

| Ответить | Цитировать | Написать

оптимизация запроса

#33270105

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

Формально, условие объединения и условие выборки -- вещи разные, и оптимизатор может заметить их эквивалентность, а может нет, это уж как повезёт. Подумайте над формированием структурно правильных запросов.

...

Рейтинг:

0 / 0

14.09.2005, 23:40:32

| Ответить | Цитировать | Написать

оптимизация запроса

#33270110

Dima S

Гость

Формально может и разные.

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

Т.е. mysql в таких случаях нужно специально тыкать носом?

...

Рейтинг:

0 / 0

14.09.2005, 23:53:34

| Ответить | Цитировать | Написать

оптимизация запроса

#33270118

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

Хорошо, назовите это не строить адекватные запросы, а тыкать носом.
Собственно, вы же сами выяснили, что да, от того, где указать условие, в объединении или в выборке -- скорость запроса зависит значительно, что вы хотите услышать, кроме рекоммендации строить запросы так, чтобы выборка осуществлялась быстро? (благо это самое "так" очевидно)
Вы пришли сюда пофлеймить?

...

Рейтинг:

0 / 0

15.09.2005, 00:35:50

| Ответить | Цитировать | Написать

оптимизация запроса

#33271400

Dima S

Гость

Нет, не пофлеймить, а обсудить особенность mysql, которая мне показалась странной.

Эта особенность, если она есть, повлечет заметную переделку в уже существующем коде для генерации запросов и сейчас важно услышать мнение специалистов по этому вопросу. Возможно, я в чем-то не до конца разобрался.

Не считаю, что один приведенный выше запрос адекватнее или стректурно правильнее другого.

...

Рейтинг:

0 / 0

15.09.2005, 14:47:05

| Ответить | Цитировать | Написать

оптимизация запроса

#33271467

Astron

Гость

Dima S
Т.е. mysql в таких случаях нужно специально тыкать носом?
Так же как и Оракл, и другие базы. Про Оракл скажу, что смена дефолтовой установки оптимизатора на сервере может засадить заточенные под старую установку запросы на раз. Поэтому там есть хинты, а тут их аналог USE|IGNORE|FORCE INDEX|KEY. Но правильно составленный запрос, первым же шагом отсекающий 99% лишнего, рулит полюбому....

...

Рейтинг:

0 / 0

15.09.2005, 15:07:22

| Ответить | Цитировать | Написать

оптимизация запроса

#33271658

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

Dima S
Не считаю, что один приведенный выше запрос адекватнее или стректурно правильнее другого.
Приведите план обоих запросов и мы сможем предметно обсудить адекватность каждого из них.

...

Рейтинг:

0 / 0

15.09.2005, 16:01:35

| Ответить | Цитировать | Написать

оптимизация запроса

#33271740

Astron

Гость

Dima Sпеределку в уже существующем коде для генерации запросов и сейчас важно услышать мнение специалистов по этому вопросу. Возможно, я в чем-то не до конца разобрался.

Не считаю, что один приведенный выше запрос адекватнее или стректурно правильнее другого.
А, блин, вот в чем вопрос! Ну, тут ответ будет такой: - производительность запроса и его структурная правильность вещи абсолютно разные. Зачастую быстрее работает как раз более сложный запрос, активно использующий UNION и подзапросы вместо JOIN, это почти правило для некоторых наборов данных. Причем это относится ко всем серверам, с которыми я работал. Задача автоматической генерации оптимальных запросов наверное не решается. Точнее, можно ввести в параметры такого генератора значения, характеризующие как исходные данные, так и предполагаемый результат, а также некоторые особенности работы оптимизаторов серверов - они, разумеется, имеют место быть.
Однако, если случай довольно частный (например, запрос строит некоторое приложение к определенной БД по результатам щелканья мышом БольшогоБосса), то получить приемлимый результат можно всего лишь заставив юзера принудительно указывать ключевые поля, и самому следить за тем как строятся джойны....

...

Рейтинг:

0 / 0

15.09.2005, 16:28:43

| Ответить | Цитировать | Написать

оптимизация запроса

#33271894

Dima S

Гость

План у всех вроде одинаковый

...

Рейтинг:

0 / 0

15.09.2005, 17:06:15

| Ответить | Цитировать | Написать

оптимизация запроса

#33272523

AlTis

Участник

Откуда: Penza - Moscow

Сообщения: 944

Рейтинг: 0 / 0

ОФФ
Тут можно ознакомиться с оком по оптимизации:
http://]banzai.sp.ru/Documentation/other-doc/MySQLManual/manual.ru_MySQL_Optimisation.html

...

Рейтинг:

0 / 0

16.09.2005, 08:58:08

| Ответить | Цитировать | Написать

оптимизация запроса

#33313522

john222

Гость

У меня вопрос такой:

Есть два варианта хранения данных:
1. Например 500 таблиц, в каждой около 80000 записей
2. Собрать вышеперечисленные таблицу в одну большую.

Поиск простой, используется по одному fulltext полю.

Понятно что во 2 варианте поиск будет быстрее чем искать в 500 таблицах с помощью UNION или как-то еще. Но соединение 500 таблиц с пересчетом ID довольно ресурсоемкая задача. Вот и хочу узнать стоит ли она того?

Но на сколько быстрее второй вариант первого? 5, 10, 30 %

...

Рейтинг:

0 / 0

09.10.2005, 14:14:35

| Ответить | Цитировать | Написать

13 сообщений из 13, страница 1 из 1

Форумы / MySQL [игнор отключен] [закрыт для гостей] / оптимизация запроса

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=47&fpage=646&tid=1853581]:	0ms
get settings:	8ms
get forum list:	11ms
check forum access:	3ms
check topic access:	3ms
track hit:	76ms
get topic data:	8ms
get forum data:	2ms
get page messages:	39ms
get tp. blocked users:	1ms
others:	238ms

total:	389ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы