MySQL: как управлять порядком join и left join в одном запросе?
мда....
select DISTINCT mans.id
FROM mans
LEFT JOIN mans_autos ON mans_autos.man_id = mans.id
LEFT JOIN autos ON autos.id = mans_autos.auto_id
LEFT JOIN marks ON (marks.id = autos.mark_id AND marks.name = 'ВАЗ' AND autos.mark_id IS NULL)
LEFT JOIN mans_tels ON mans_tels.man_id = mans.id
LEFT JOIN tels ON tels.id = mans_tels.tel_id
LEFT JOIN colors ON (color.id = tels.color_id AND colors.name = 'белый' AND colors.id IS NULL)
-- а вот это убрать нафиг
-- WHERE
-- colors.id IS NULL AND marks.id IS NULL
;
жирным выделено то, на что вам стоит обратить внимание
и джойны мускуль выполняет в том порядке как написан.
если медленно - используйте индексы, сделайте explain запроса
если планер не использует ваши индексы можно принудительно указать их в запросе
хотя условие colors.id IS NULL выглядит странно, только если у вас ид неуникальный ключ, но это глупо.
Кстати, что вы там говорили про портфолио и умные книжки?
select DISTINCT mans.id
FROM mans
LEFT JOIN mans_autos ON mans_autos.man_id = mans.id
LEFT JOIN autos ON autos.id = mans_autos.auto_id
LEFT JOIN marks ON (marks.id = autos.mark_id AND marks.name = 'ВАЗ' AND autos.mark_id IS NULL)
LEFT JOIN mans_tels ON mans_tels.man_id = mans.id
LEFT JOIN tels ON tels.id = mans_tels.tel_id
LEFT JOIN colors ON (color.id = tels.color_id AND colors.name = 'белый' AND colors.id IS NULL)
-- а вот это убрать нафиг
-- WHERE
-- colors.id IS NULL AND marks.id IS NULL
;
жирным выделено то, на что вам стоит обратить внимание
и джойны мускуль выполняет в том порядке как написан.
если медленно - используйте индексы, сделайте explain запроса
если планер не использует ваши индексы можно принудительно указать их в запросе
хотя условие colors.id IS NULL выглядит странно, только если у вас ид неуникальный ключ, но это глупо.
Кстати, что вы там говорили про портфолио и умные книжки?
да не, все правильно было, толстопуз фильтрует уже результат, в котором нули означают что не нашелся джоинами белый цвет и марка ваз.
2 толстопуз,
левый join не гарантирует уникальности
с внутренним джоином мне кажется здесь фокус не получится, я бы на самом деле посмотрел в сторону NOT EXIST на цвет и на марку в WHERE
или на subselect ы, но они обычно хуже в плане производительности
З.Ы. mans кошернее переименовать в men
2 толстопуз,
левый join не гарантирует уникальности
с внутренним джоином мне кажется здесь фокус не получится, я бы на самом деле посмотрел в сторону NOT EXIST на цвет и на марку в WHERE
или на subselect ы, но они обычно хуже в плане производительности
З.Ы. mans кошернее переименовать в men
Ну и еще. Поскольку любые джойны можно представлять как вложенные циклы, то при такой группировке как для Акцесса... можно ли оптимизатору "как-то" объяснить что ОБА левых джойна можно делать в ОДНОМ внутреннем цикле, поскольку они не зависят друг от друга, типа:
foreach mans ...
foreach mans_tels, mans_autos ... (в принципе, допустимо пробегать совместно)
foreach tels&colors, autos&marks ...
if P is null then add_record()
end
end
end
В этом случае просмотр главной таблицы запроса производится однократно...
foreach mans ...
foreach mans_tels, mans_autos ... (в принципе, допустимо пробегать совместно)
foreach tels&colors, autos&marks ...
if P is null then add_record()
end
end
end
В этом случае просмотр главной таблицы запроса производится однократно...
Вот такая группировка и дает увеличение времени до 19 секунд...
Ладно, фиг с ним, порядком. Нет так нет. В ANSI - точно не помню, возможно действительно нет. У мелкософта - была таки приятная фича... и оптимизировалась ими нефигово...
Остался второй вопрос: необходимость применения DISTINCT или GROUP BY (последний значительно быстрее)... откуда берутся дубликаты? Причем, я могу получить при 4-х (в реальности а не 2 как в примере) таблицах связи до 12 дублей, в зависимости от того, сколько "прочих" удачных совпадений найдено при отборе записей в разных таблицах и их справочниках... проверил уже.
П.С. вчера вышел Мускул 5.5.8 "стабильный релиз"... буду пробовать... антиресно как он себя ведет... типа исправлено много чего. Уже закачиваю...
Ладно, фиг с ним, порядком. Нет так нет. В ANSI - точно не помню, возможно действительно нет. У мелкософта - была таки приятная фича... и оптимизировалась ими нефигово...
Остался второй вопрос: необходимость применения DISTINCT или GROUP BY (последний значительно быстрее)... откуда берутся дубликаты? Причем, я могу получить при 4-х (в реальности а не 2 как в примере) таблицах связи до 12 дублей, в зависимости от того, сколько "прочих" удачных совпадений найдено при отборе записей в разных таблицах и их справочниках... проверил уже.
П.С. вчера вышел Мускул 5.5.8 "стабильный релиз"... буду пробовать... антиресно как он себя ведет... типа исправлено много чего. Уже закачиваю...
перепроверю. Цифирьку уже не помню.
Насчет "увеличьте память" и т.д. Что есть, тем и пользуюсь. Бабок дадите на увеличение, или просто совет ради красного словца?
ИМХО: программа должна работать в ЛЮБОМ случае. Я же писал, что время выполнения меня вполне устраивает... я же понимаю, что это далеко не Крей...
Насчет "увеличьте память" и т.д. Что есть, тем и пользуюсь. Бабок дадите на увеличение, или просто совет ради красного словца?
ИМХО: программа должна работать в ЛЮБОМ случае. Я же писал, что время выполнения меня вполне устраивает... я же понимаю, что это далеко не Крей...
дубликаты беруться из того как работает джоин.
Если есть чувак ч, у которого две машины не ваз A1, A2 и 2 не белых телефона T1, T2 то в результате запроса из заглавного поста, джоин даст
4 тройки
Ч, A1, T1
Ч, A1, T2
Ч, A2 T1
Ч, A2, T2
Которые благополучно пройдут все фильтры и в результате дадут 4 раза Ч
З.Ы. NOT EXISTS должен быть быстрым
Если есть чувак ч, у которого две машины не ваз A1, A2 и 2 не белых телефона T1, T2 то в результате запроса из заглавного поста, джоин даст
4 тройки
Ч, A1, T1
Ч, A1, T2
Ч, A2 T1
Ч, A2, T2
Которые благополучно пройдут все фильтры и в результате дадут 4 раза Ч
З.Ы. NOT EXISTS должен быть быстрым
у вас изменение конфигурации мускуля платное??? 
Типовое применение левого объединения - поиск отсутствующих записей в таблицах с ВНЕШНИМ ключом, который, как известно НЕ уникален... просмотрети еще раз пример внимательнее.Проверил. С временными таблицами дает 15сек.
А при чем тут "конфигурация мускуля", ежели её на всем компе всего-то полгектара... ?!? Я ему её откуда "выкопаю"?
View, в реальности не "проканает"... в разработке использован абстрактный подход... имена таблиц и полей - выдираются из системы описания абстрактного уровня динамически... и запрос формируется и подготавливается операцией prepare из текстовой строки в конечном счете...
Тут не так просто оно всё закручено...
А ежели я еще "по секрету" скажу, что частично всё это ПАРСИТСЯ из строки Json кодом процедуры на Мускуле...
Тут не так просто оно всё закручено...
А ежели я еще "по секрету" скажу, что частично всё это ПАРСИТСЯ из строки Json кодом процедуры на Мускуле...
Вот, если правильно трактовать описание джойнов у мускула (и оператор explain), то всё не так:
На примере одной части объединений: "Чувак" -> "СвязьЧ-А" -> "Авто" -> "Марка" получаем:
Пусть будут:
"Чувак" (Ч1, Ч2, Ч3, Ч4)
"Авто" (А1=ВАЗ, А2=др, А3=ВАЗ, А4=др, А5=др)
"СвязьЧ-А" (Ч1+А2, Ч1+А1, Ч2+А3, Ч3+А4, Ч3+А5) чувак №4 ваще без авто.
первая таблица выборки = "марка авто" в которой нужен первичный ключ для записи "ВАЗ" - это 1 запись. Так оно и в explain.
из таблицы "авто" - выбираем только те записи, где авто = ВАЗ, это (А3,А1). Так оно и в explain. use not exists!
из таблицы связи выбираем чуваков, связанных с этими авто, это тоже всего(!) две записи Ч1 и Ч2
затем собираем всю таблицу чуваков, проставляя не нулевой идент марки для Ч1 и Ч2 и нулевой для всех остальных... по условию "веры" оставляем только тех где оказался нулевой идент марки... так оно и в explain прописано (not exists)... откуда взялись повторы?
На примере одной части объединений: "Чувак" -> "СвязьЧ-А" -> "Авто" -> "Марка" получаем:
Пусть будут:
"Чувак" (Ч1, Ч2, Ч3, Ч4)
"Авто" (А1=ВАЗ, А2=др, А3=ВАЗ, А4=др, А5=др)
"СвязьЧ-А" (Ч1+А2, Ч1+А1, Ч2+А3, Ч3+А4, Ч3+А5) чувак №4 ваще без авто.
первая таблица выборки = "марка авто" в которой нужен первичный ключ для записи "ВАЗ" - это 1 запись. Так оно и в explain.
из таблицы "авто" - выбираем только те записи, где авто = ВАЗ, это (А3,А1). Так оно и в explain. use not exists!
из таблицы связи выбираем чуваков, связанных с этими авто, это тоже всего(!) две записи Ч1 и Ч2
затем собираем всю таблицу чуваков, проставляя не нулевой идент марки для Ч1 и Ч2 и нулевой для всех остальных... по условию "веры" оставляем только тех где оказался нулевой идент марки... так оно и в explain прописано (not exists)... откуда взялись повторы?
сорри, мне сложно вчитываться во всю логику, которая написана
просто первый джоин
LEFT JOIN mans_autos ON mans_autos.man_id = mans.id
уже наобъединяет всех чуваков с их машинами, включая нули для чуваков у которых нет машин вообще. Меньше результат джоина от последующих применений левых джоинов не будет ...
просто первый джоин
LEFT JOIN mans_autos ON mans_autos.man_id = mans.id
уже наобъединяет всех чуваков с их машинами, включая нули для чуваков у которых нет машин вообще. Меньше результат джоина от последующих применений левых джоинов не будет ...
К сожалению, что имею. Не мною придумано... моя задача "оптимизорать по возможности"...
Насчет примера, не проблема. Вот то, что получилось из исходной задачи в виде конечного мускульного кода:
DROP TEMPORARY TABLE IF EXISTS tmpNotes;
CREATE TEMPORARY TABLE tmpNotes SELECT
cnn.`company` as id
FROM kernel.crm_notes AS cnn
JOIN kernel.crm_notes_results AS cnrr ON cnrr.`id`=cnn.`result_id` AND cnrr.`id` IN ( 6,22,16,23,15,17)
JOIN `crm_notes_categories` AS cnc ON
(cnc.`note_id` = cnn.`id` AND cnc.`category_id` = 6)
WHERE
cnn.`created_at` 0
;
DROP TEMPORARY TABLE IF EXISTS tmpMans;
CREATE TEMPORARY TABLE tmpMans SELECT
atu.`firm_id` as id
FROM `crm_attachments` AS atu
JOIN `crm_attachments_categories` AS atuc ON atuc.`attachment_id` = atu.`id`
WHERE
atu.`active` > 0 AND atuc.`active` > 0
AND atuc.`category_id` = 6 AND atuc.`type_id` IN (1,2,3)
;
DROP TEMPORARY TABLE IF EXISTS tmpDeps;
CREATE TEMPORARY TABLE tmpDeps SELECT
af1.`m_company_id` as id
FROM `crm_attachments_office` AS af1
JOIN `crm_attachments_office_categories` AS atfc ON atfc.`attachment_id` = af1.`id`
WHERE
af1.`active` > 0 AND af1.`m_company_function_id` = 8
AND atfc.`active` > 0
AND atfc.`category_id` = 6 AND atfc.`type_id` IN (1, 2, 3)
;
DROP TEMPORARY TABLE IF EXISTS tmpPubs;
CREATE TEMPORARY TABLE tmpPubs SELECT
ocp1.`m_company_id` as id
FROM `pubsys_order_category_parts_products` AS ocp1
WHERE
ocp1.`part_number` = 27
;
SELECT mc.`id`
FROM `m_company` AS mc
JOIN `pubsys_order_category_parts_products` AS ocpp ON ocpp.`m_company_id` = mc.`id`
LEFT JOIN tmpNotes AS cnn ON cnn.`id` = mc.`id`
LEFT JOIN tmpMans AS atu ON atu.`id` = mc.`id`
LEFT JOIN tmpDeps AS af1 ON af1.`id` = mc.`id`
LEFT JOIN tmpPubs AS ocp1 ON ocp1.`id` = mc.`id`
WHERE mc.`active` > 0
AND ocpp.`category_id` = 6 AND ocpp.`active` = 2
AND ocpp.`part_number` IN (22,24,26)
AND ocpp.`product_id` IN (28,30,76)
AND cnn.`id` IS NULL
AND atu.`id` IS NULL
AND af1.`id` IS NULL
AND ocp1.`id` IS NULL
#GROUP BY mc.`id`
;
COMMIT;
Слегка причесано, потому как игрался, пытаясь понять чего тормозит... вот это исполняется 15сек на текущих данных.
А вот это, всего 5-6сек.:
SELECT mc.`id`
FROM `m_company` AS mc
JOIN `pubsys_order_category_parts_products` AS ocpp ON ocpp.`m_company_id` = mc.`id`
LEFT JOIN crm_notes AS cnn ON
(cnn.`company` = ocpp.`m_company_id` AND cnn.`created_at` 0)
LEFT JOIN crm_notes_results AS cnrr ON cnrr.`id`=cnn.`result_id` AND cnrr.`id` IN ( 6,22,16,23,15,17)
LEFT JOIN `crm_notes_categories` AS cnc ON
(cnc.`note_id` = cnn.`id` AND cnc.`category_id` = 6)
LEFT JOIN `crm_attachments` AS atu ON (atu.`firm_id` = mc.`id` AND atu.`active` > 0)
LEFT JOIN `crm_attachments_categories` AS atuc ON (
atuc.`attachment_id` = atu.`id` AND atuc.`active` > 0
AND atuc.`category_id` = 6 AND atuc.`type_id` IN (1,2,3))
LEFT JOIN `crm_attachments_office` AS atf ON (
atf.`m_company_id` = mc.`id` AND atf.`active` > 0 AND atf.`m_company_function_id` = 8 )
LEFT JOIN `crm_attachments_office_categories` AS atfc ON (
atfc.`attachment_id` = atf.`id` AND atfc.`active` > 0
AND atfc.`category_id` = 6 AND atfc.`type_id` IN (1, 2, 3))
LEFT JOIN `pubsys_order_category_parts_products` AS ocp1 ON
(ocp1.`m_company_id` = ocpp.`m_company_id` AND ocp1.`part_number` = 27)
WHERE mc.`active` > 0
AND ocpp.`category_id` = 6 AND ocpp.`active` = 2
AND ocpp.`part_number` IN (22,24,26)
AND ocpp.`product_id` IN (28,30,76)
# AND atu.`id` IS NULL
AND atuc.`attachment_id` IS NULL
# AND atf.`id` IS NULL
AND atfc.`attachment_id` IS NULL
# AND cnn.`id` IS NULL
AND cnrr.`id` IS NULL
AND cnc.note_id IS NULL
AND ocp1.`id` IS NULL
GROUP BY mc.`id`
;
Тоже причесано мною... закомментированы попытки "понять" особенности поведения мускуля...Это рабочий вариант.
Насчет примера, не проблема. Вот то, что получилось из исходной задачи в виде конечного мускульного кода:
DROP TEMPORARY TABLE IF EXISTS tmpNotes;
CREATE TEMPORARY TABLE tmpNotes SELECT
cnn.`company` as id
FROM kernel.crm_notes AS cnn
JOIN kernel.crm_notes_results AS cnrr ON cnrr.`id`=cnn.`result_id` AND cnrr.`id` IN ( 6,22,16,23,15,17)
JOIN `crm_notes_categories` AS cnc ON
(cnc.`note_id` = cnn.`id` AND cnc.`category_id` = 6)
WHERE
cnn.`created_at` 0
;
DROP TEMPORARY TABLE IF EXISTS tmpMans;
CREATE TEMPORARY TABLE tmpMans SELECT
atu.`firm_id` as id
FROM `crm_attachments` AS atu
JOIN `crm_attachments_categories` AS atuc ON atuc.`attachment_id` = atu.`id`
WHERE
atu.`active` > 0 AND atuc.`active` > 0
AND atuc.`category_id` = 6 AND atuc.`type_id` IN (1,2,3)
;
DROP TEMPORARY TABLE IF EXISTS tmpDeps;
CREATE TEMPORARY TABLE tmpDeps SELECT
af1.`m_company_id` as id
FROM `crm_attachments_office` AS af1
JOIN `crm_attachments_office_categories` AS atfc ON atfc.`attachment_id` = af1.`id`
WHERE
af1.`active` > 0 AND af1.`m_company_function_id` = 8
AND atfc.`active` > 0
AND atfc.`category_id` = 6 AND atfc.`type_id` IN (1, 2, 3)
;
DROP TEMPORARY TABLE IF EXISTS tmpPubs;
CREATE TEMPORARY TABLE tmpPubs SELECT
ocp1.`m_company_id` as id
FROM `pubsys_order_category_parts_products` AS ocp1
WHERE
ocp1.`part_number` = 27
;
SELECT mc.`id`
FROM `m_company` AS mc
JOIN `pubsys_order_category_parts_products` AS ocpp ON ocpp.`m_company_id` = mc.`id`
LEFT JOIN tmpNotes AS cnn ON cnn.`id` = mc.`id`
LEFT JOIN tmpMans AS atu ON atu.`id` = mc.`id`
LEFT JOIN tmpDeps AS af1 ON af1.`id` = mc.`id`
LEFT JOIN tmpPubs AS ocp1 ON ocp1.`id` = mc.`id`
WHERE mc.`active` > 0
AND ocpp.`category_id` = 6 AND ocpp.`active` = 2
AND ocpp.`part_number` IN (22,24,26)
AND ocpp.`product_id` IN (28,30,76)
AND cnn.`id` IS NULL
AND atu.`id` IS NULL
AND af1.`id` IS NULL
AND ocp1.`id` IS NULL
#GROUP BY mc.`id`
;
COMMIT;
Слегка причесано, потому как игрался, пытаясь понять чего тормозит... вот это исполняется 15сек на текущих данных.
А вот это, всего 5-6сек.:
SELECT mc.`id`
FROM `m_company` AS mc
JOIN `pubsys_order_category_parts_products` AS ocpp ON ocpp.`m_company_id` = mc.`id`
LEFT JOIN crm_notes AS cnn ON
(cnn.`company` = ocpp.`m_company_id` AND cnn.`created_at` 0)
LEFT JOIN crm_notes_results AS cnrr ON cnrr.`id`=cnn.`result_id` AND cnrr.`id` IN ( 6,22,16,23,15,17)
LEFT JOIN `crm_notes_categories` AS cnc ON
(cnc.`note_id` = cnn.`id` AND cnc.`category_id` = 6)
LEFT JOIN `crm_attachments` AS atu ON (atu.`firm_id` = mc.`id` AND atu.`active` > 0)
LEFT JOIN `crm_attachments_categories` AS atuc ON (
atuc.`attachment_id` = atu.`id` AND atuc.`active` > 0
AND atuc.`category_id` = 6 AND atuc.`type_id` IN (1,2,3))
LEFT JOIN `crm_attachments_office` AS atf ON (
atf.`m_company_id` = mc.`id` AND atf.`active` > 0 AND atf.`m_company_function_id` = 8 )
LEFT JOIN `crm_attachments_office_categories` AS atfc ON (
atfc.`attachment_id` = atf.`id` AND atfc.`active` > 0
AND atfc.`category_id` = 6 AND atfc.`type_id` IN (1, 2, 3))
LEFT JOIN `pubsys_order_category_parts_products` AS ocp1 ON
(ocp1.`m_company_id` = ocpp.`m_company_id` AND ocp1.`part_number` = 27)
WHERE mc.`active` > 0
AND ocpp.`category_id` = 6 AND ocpp.`active` = 2
AND ocpp.`part_number` IN (22,24,26)
AND ocpp.`product_id` IN (28,30,76)
# AND atu.`id` IS NULL
AND atuc.`attachment_id` IS NULL
# AND atf.`id` IS NULL
AND atfc.`attachment_id` IS NULL
# AND cnn.`id` IS NULL
AND cnrr.`id` IS NULL
AND cnc.note_id IS NULL
AND ocp1.`id` IS NULL
GROUP BY mc.`id`
;
Тоже причесано мною... закомментированы попытки "понять" особенности поведения мускуля...
Это рабочий вариант.Исходных ПХП не привожу, потому как там нет единого запроса. Все части передаются в абстрактный метод Паджинатора (отнаследован от Зендового) в виде json-отдельных элементов из строк ПХП массива без главной таблицы... она добавляется позже, как собственно и поисковая строка...
Собственно, это только часть запроса... там еще с десяток таблиц может "доклеиться"...
Ну а на вопрос "нах... этот гемморой?"... у меня пока объяснение только одно: надо же было зарплату оправдывать...
Собственно, это только часть запроса... там еще с десяток таблиц может "доклеиться"...
Ну а на вопрос "нах... этот гемморой?"... у меня пока объяснение только одно: надо же было зарплату оправдывать...
Пасибки. Есть всё. И индексы, где надо и замена на константы... при формировании временных таблиц местоположение условия - практически не влияет ни на что. Там же не левое объединение... Мускул их все равно перетащит в предложение "вера"...
По объемам:
m_company = 70_000, ocpp = 75000, cnn = 72000, cnc=70000, cnrr=14, atu=45000, atuc=55000, atf=20000, atfc=35000 где-то так.
Собственно это уже оптимизированный запрос.
Меня беспокоит не его скорость работы, а необходимость применения последней строки - GROUP BY. Потому как уже показывал, что если следовать описанию самого Мускула о зависимостях таблиц и результату работы его explain, то множественного результата получаться не должно... а оно - есть.
Похоже, что объяснение примерно такое, как здесь уже приводилось другим автором: в результат проскакивают строки, которые "по хорошему" должны были отсеяться еще на ранней стадии внутренних объединений. Косвенным подтверждением считаю порядок таблиц в explain - он везде равен 1. То есть вся обработка вроде как проходит в "одном" цикле, если правильно это понимаю... В этом случае, да должно получиться "много"... и как раз столько, сколько "не ВАЗов" есть у чувака. Очень похоже на реальность.
По объемам:
m_company = 70_000, ocpp = 75000, cnn = 72000, cnc=70000, cnrr=14, atu=45000, atuc=55000, atf=20000, atfc=35000 где-то так.
Собственно это уже оптимизированный запрос.
Меня беспокоит не его скорость работы, а необходимость применения последней строки - GROUP BY. Потому как уже показывал, что если следовать описанию самого Мускула о зависимостях таблиц и результату работы его explain, то множественного результата получаться не должно... а оно - есть.
Похоже, что объяснение примерно такое, как здесь уже приводилось другим автором: в результат проскакивают строки, которые "по хорошему" должны были отсеяться еще на ранней стадии внутренних объединений. Косвенным подтверждением считаю порядок таблиц в explain - он везде равен 1. То есть вся обработка вроде как проходит в "одном" цикле, если правильно это понимаю... В этом случае, да должно получиться "много"... и как раз столько, сколько "не ВАЗов" есть у чувака. Очень похоже на реальность.
как раз таки влияет. заджойнить все по широкому условию, а потом отфильтровать по узкому более накладно, чем заджойнить сразу по узкому. если условие стоит внутри джойна, то оно применяется до джойна на таблицы, после чего происходит джойн, а если после - то размер данных которые _потом_ фильтруются больше во многих случаях.
вы не правильно понимаете - это уровень, а не итератор. все операции одного уровня нужно выполнить в том порядке, который написан, а не паралельно их выполнять.
грубо говоря
select a.field from ( select b.filed1 from b ) as a join c on (a.field = c.field) where a.field = 5
имет подзапрос с индексом 1, и запрос с индексом два - это означает, что сначала выполнить нужно подзапрос (или подзапросЫ если они еще есть - у них индекс 1), а потом произвести из них джойн(Ы) (индекс 2).
но в рамках одного уровня (индекса) запросы выполняются ровно в том порядке в котором написаны!
это оооочень долго - у меня на нескольких таблицах (44-1,5 миллиона строк) выполняются джойны быстрее, но правда и памяти там больше
.
Но на нормальном кэшэ БД и нормально сделанных индексах три-четыре джойна из таких таблиц выполняются 2-8 секунд (если я на виртуалку откусываю полтора гигабайта).
Смотрите настройки мускуля - "искаропки" у него двольно минималистическая конфигурация, смотрите индексы - чудо-планер иногда забывает их использовать и делает фуллскан (скорее всего у вас он это делает не один раз), и их нужно принудительно подоткнуть в запрос.По хорошему бы сделать дамп-ресторе можно если из таблиц часто что-то удалятется/добавляется. 5 секунд долго, а 15 секунд - вообще заоблачно.
вы не правильно понимаете - это уровень, а не итератор. все операции одного уровня нужно выполнить в том порядке, который написан, а не паралельно их выполнять.
грубо говоря
select a.field from ( select b.filed1 from b ) as a join c on (a.field = c.field) where a.field = 5
имет подзапрос с индексом 1, и запрос с индексом два - это означает, что сначала выполнить нужно подзапрос (или подзапросЫ если они еще есть - у них индекс 1), а потом произвести из них джойн(Ы) (индекс 2).
но в рамках одного уровня (индекса) запросы выполняются ровно в том порядке в котором написаны!
это оооочень долго - у меня на нескольких таблицах (44-1,5 миллиона строк) выполняются джойны быстрее, но правда и памяти там больше
.Но на нормальном кэшэ БД и нормально сделанных индексах три-четыре джойна из таких таблиц выполняются 2-8 секунд (если я на виртуалку откусываю полтора гигабайта).
Смотрите настройки мускуля - "искаропки" у него двольно минималистическая конфигурация, смотрите индексы - чудо-планер иногда забывает их использовать и делает фуллскан (скорее всего у вас он это делает не один раз), и их нужно принудительно подоткнуть в запрос.По хорошему бы сделать дамп-ресторе можно если из таблиц часто что-то удалятется/добавляется. 5 секунд долго, а 15 секунд - вообще заоблачно.
Не знаю как получить полный explain для всех 5-и запросов с созданием временных таблиц. Пришлось убрать TEMPORARY и сделать анализ по отдельности каждого запроса... может это не верно... но думаю достаточно для того, чтобы понять "почему"...
После проведенных экспериментов результат прост:
НИКАК.
Порядок указания таблиц - особенно при наличии смешанных join (внутренние и левые) - никакой роли не играет. Мускуль 5.1 - точно. Оптимизатор, все равно расставляет самостоятельно. Можно, что-то сделать только указывая явно всякие индексы...
Тему можно закрывать. Поехал компилять версию 5.5.8...
НИКАК.
Порядок указания таблиц - особенно при наличии смешанных join (внутренние и левые) - никакой роли не играет. Мускуль 5.1 - точно. Оптимизатор, все равно расставляет самостоятельно. Можно, что-то сделать только указывая явно всякие индексы...
Тему можно закрывать. Поехал компилять версию 5.5.8...