|
Оптимизировать 23 join
|
|||
---|---|---|---|
#18+
SELECT * FROM FROM machines m JOIN parts mp ON mp.id = m.type_id JOIN models mm ON mm.id = m.model_id JOIN modems mod ON mod.id = m.modem_id JOIN money_machines coin_mm ON coin_mm.id = m.coin_id JOIN money_machine_creators mmc_coin ON mmc_coin.id = coin_mm.creator_id JOIN money_machines bank_mm ON bank_mm.id = m.banknote_id JOIN money_machine_creators mmc_bank ON mmc_bank.id = bank_mm.creator_id JOIN divisions d ON d.id = m.division_id JOIN regions r ON r.id = d.region_id JOIN kkt_types kt ON kt.id = m.kkt_type_id JOIN users u3 ON u3.id = m.operator_id JOIN user_roles ur3 ON ur3.id = u3.role_id JOIN divisions d3 ON d3.id = u3.division_id JOIN regions r3 ON r3.id = d3.region_id JOIN users u4 ON u4.id = m.st_id JOIN user_roles ur4 ON ur4.id = u4.role_id JOIN divisions d4 ON d4.id = u4.division_id JOIN regions r4 ON r4.id = d4.region_id JOIN users u5 ON u5.id = m.manager_id JOIN user_roles ur5 ON ur5.id = u5.role_id JOIN divisions d5 ON d5.id = u5.division_id JOIN regions r5 ON r5.id = d5.region_id JOIN raws edr ON edr.machine_id = m.id; Возможно? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2017, 17:09 |
|
Оптимизировать 23 join
|
|||
---|---|---|---|
#18+
Andrew B., А что значит оптимизировать? Он у вас тормозит сильно? И что именно вы этим запросом считаете? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2017, 17:50 |
|
Оптимизировать 23 join
|
|||
---|---|---|---|
#18+
Andrew B.SELECT * FROM FROM machines m JOIN parts mp ON mp.id = m.type_id JOIN models mm ON mm.id = m.model_id JOIN modems mod ON mod.id = m.modem_id JOIN money_machines coin_mm ON coin_mm.id = m.coin_id JOIN money_machine_creators mmc_coin ON mmc_coin.id = coin_mm.creator_id JOIN money_machines bank_mm ON bank_mm.id = m.banknote_id JOIN money_machine_creators mmc_bank ON mmc_bank.id = bank_mm.creator_id JOIN divisions d ON d.id = m.division_id JOIN regions r ON r.id = d.region_id JOIN kkt_types kt ON kt.id = m.kkt_type_id JOIN users u3 ON u3.id = m.operator_id JOIN user_roles ur3 ON ur3.id = u3.role_id JOIN divisions d3 ON d3.id = u3.division_id JOIN regions r3 ON r3.id = d3.region_id JOIN users u4 ON u4.id = m.st_id JOIN user_roles ur4 ON ur4.id = u4.role_id JOIN divisions d4 ON d4.id = u4.division_id JOIN regions r4 ON r4.id = d4.region_id JOIN users u5 ON u5.id = m.manager_id JOIN user_roles ur5 ON ur5.id = u5.role_id JOIN divisions d5 ON d5.id = u5.division_id JOIN regions r5 ON r5.id = d5.region_id JOIN raws edr ON edr.machine_id = m.id; Возможно? возможно, добавь сюда where... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2017, 11:50 |
|
Оптимизировать 23 join
|
|||
---|---|---|---|
#18+
Соглашусь с автором: https://habrahabr.ru/company/oleg-bunin/blog/319018/ авторСледующий запрос-проблема – Join на 300 таблиц. Проблема состоит в том, что будет 300! вариантов, как этот Join сделать. Более того, если вам понадобилось написать Join на 300 таблиц, это значит, что у вас очень плохо с дизайном схемы, что-то очень не продумано, и надо много чего переделывать. В норме Join – это на две, на три таблицы. Иногда на пять, изредка на десять, но это крайние случаи. Когда Join'ов сотни, любой БД станет плохо. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2017, 16:44 |
|
Оптимизировать 23 join
|
|||
---|---|---|---|
#18+
BDSM, с большой вер-ю большая часть -- короткие справочники, легко подцепляемые к основной табле хеш-джойном. вот когда вы цепляете друг на друга пяток многомилионных табличек -- там сразу начинается проблемы (что тягать нестедом, что хешем, и с какой стороны начинать). сам запрос в этом случае без where уж точно никому никогда не нужен. да и тут видимо аффтар имеет в виду вьюху, к которой будет обращаться в большинстве случаев фильтруя по каким-то параметрам. тут то он и обнаружит, что в зав-ти от того, с какой стороны он фильтрует, сплошь и рядом дешевле руками написать конкретный запрос , а не насиловать оптимизатор выбором планов фильтрации обобщённого вью. к тому же в зав-ти от where в задаче оптимизации начнут появляться пожелания к наличию тех или иных индексов. в том виде как поставлен вопрос аффтаром -- о них рано даже начинать думать. т.е. оптимизация начнется с анализа наиболее частых и/или нужных запросов к. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2017, 18:20 |
|
Оптимизировать 23 join
|
|||
---|---|---|---|
#18+
Andrew B., Ну... Можно вместо JOIN использовать что то вроде Код: sql 1. 2. 3. 4. 5.
Это если вам достаточно одного поля с соответствующей БД. Если немного "наплевать" на оперативность, то можно создать мат-вьюху, которая будет раз n-ед.времени обновляться. Если "наплевать" на скорость запроса, то можно вынести его в простую вьюху. Но тогда надо смотреть на план выполнения запроса и тюнить индексы, чтобы добиться максимальной производительности. А так не надо бояться JOIN-ов. :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.01.2017, 08:27 |
|
Оптимизировать 23 join
|
|||
---|---|---|---|
#18+
> mad_nazgul ...вместо JOIN использовать... Код: sql 1. 2. 3. 4. 5.
Справедливости ради - это left join :-) С уважением, Polesov. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.01.2017, 21:12 |
|
|
start [/forum/topic.php?fid=53&fpage=79&tid=1996755]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
34ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
2ms |
others: | 11ms |
total: | 139ms |
0 / 0 |