powered by simpleCommunicator - 2.0.31     © 2024 Programmizd 02
Форумы / MySQL [закрыт для гостей] / Господа базоёбы, скок сюды
25 сообщений из 242, страница 7 из 10
Господа базоёбы, скок сюды
    #60304
Tammy Jo Saint Cloud
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
basename  09.06.2022, 16:12
[игнорируется]
PaNik  09.06.2022, 15:59
[игнорируется]
basename  09.06.2022, 15:54
[игнорируется]
PaNik [игнорируется] 

Есть в консоли выполнения общее время, 0.016 sec

Одинаковое для обеих запросов
Размер таблиц небольшой
Правильно ли я понимаю, грубо говоря, в случае left join ему надо просто к большому куску надо присобачить ещё кусочек, а в случае join, отсечь ненужное из двух кусков и уже их склеить? тогда вроде бы логично, что join дороже и дольше должен выполняться?
нет и не всегда
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60306
cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[игнорирует гостей]
Гесты и игнорируемые идут по CSS
basename  09.06.2022, 16:12
[игнорируется]
PaNik  09.06.2022, 15:59
[игнорируется]
basename  09.06.2022, 15:54
[игнорируется]
PaNik [игнорируется] 

Есть в консоли выполнения общее время, 0.016 sec

Одинаковое для обеих запросов
Размер таблиц небольшой
Правильно ли я понимаю, грубо говоря, в случае left join ему надо просто к большому куску надо присобачить ещё кусочек, а в случае join, отсечь ненужное из двух кусков и уже их склеить? тогда вроде бы логично, что join дороже и дольше должен выполняться?
Соединение будет происходить одинаково в обоих случаях, но LEFT, как правило, возвращает больше записей и поэтому выполняется медленнее
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60308
Tammy Jo Saint Cloud
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cat2  09.06.2022, 16:24
[игнорируется]
Соединение будет происходить одинаково в обоих случаях, но LEFT, как правило, возвращает больше записей и поэтому выполняется медленнее
нет
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60311
basename
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Tammy Jo Saint Cloud  09.06.2022, 16:22
[игнорируется]
basename  09.06.2022, 16:12
[игнорируется]
PaNik  09.06.2022, 15:59
[игнорируется]
basename  09.06.2022, 15:54
[игнорируется]
PaNik [игнорируется] 

Есть в консоли выполнения общее время, 0.016 sec

Одинаковое для обеих запросов
Размер таблиц небольшой
Правильно ли я понимаю, грубо говоря, в случае left join ему надо просто к большому куску надо присобачить ещё кусочек, а в случае join, отсечь ненужное из двух кусков и уже их склеить? тогда вроде бы логично, что join дороже и дольше должен выполняться?
нет и не всегда
+ ещё зависит от реализации в СУБД? MS SQL, MySQL, PostgreSQL, ORACLE?
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60313
Tammy Jo Saint Cloud
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
basename  09.06.2022, 16:26
[игнорируется]
Tammy Jo Saint Cloud  09.06.2022, 16:22
[игнорируется]
basename  09.06.2022, 16:12
[игнорируется]
PaNik  09.06.2022, 15:59
[игнорируется]
basename  09.06.2022, 15:54
[игнорируется]
...
Размер таблиц небольшой
Правильно ли я понимаю, грубо говоря, в случае left join ему надо просто к большому куску надо присобачить ещё кусочек, а в случае join, отсечь ненужное из двух кусков и уже их склеить? тогда вроде бы логично, что join дороже и дольше должен выполняться?
нет и не всегда
+ ещё зависит от реализации в СУБД? MS SQL, MySQL, PostgreSQL, ORACLE?
очень сильно зависит
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60314
cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[игнорирует гостей]
Гесты и игнорируемые идут по CSS
Tammy Jo Saint Cloud  09.06.2022, 16:24
[игнорируется]
cat2  09.06.2022, 16:24
[игнорируется]
Соединение будет происходить одинаково в обоих случаях, но LEFT, как правило, возвращает больше записей и поэтому выполняется медленнее
нет
Обоснуй
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60315
Горбатый ёж
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хуяссе планы...
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60316
basename
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Горбатый ёж  09.06.2022, 16:28
[игнорируется]
Хуяссе планы...
что с ними не так? )
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60317
Горбатый ёж
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
basename  09.06.2022, 16:29
[игнорируется]
Горбатый ёж  09.06.2022, 16:28
[игнорируется]
Хуяссе планы...
что с ними не так? )
А есть текстовый вариант?
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60319
Tammy Jo Saint Cloud
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cat2  09.06.2022, 16:27
[игнорируется]
Tammy Jo Saint Cloud  09.06.2022, 16:24
[игнорируется]
cat2  09.06.2022, 16:24
[игнорируется]
Соединение будет происходить одинаково в обоих случаях, но LEFT, как правило, возвращает больше записей и поэтому выполняется медленнее
нет
Обоснуй
а что, и правда надо? это же знания из детского сада

ну ладно, что стар, что мал...

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

тогда для select * from Tab1 left join tab2 on a=b будет один вариант соединения - мы идем по Таб1 и лепим к ней Таб2
а вот для select * from Tab1 left INNER join tab2 on a=b будет уже 2 варианта - идти по таб1 и лепить таб2 - или идти по таб2 и лепить к ней таб1
таким образом "Одинаково в обоих случаях" - немного неправильно.

Второй момент - "лефт выполнятеся быстрее, т.к." - во первых не всегда "больше записей" (и как правило - ровно столько же записей - или даже МЕНЬШЕ)
во вторых (зависит от случая) лефт может (и будет) читать с диска меньше данных для "правой" таблицы - следовательно, сам по себе запро будет выполнятся быстрее
Ну и в некоторых случаях лефт все таки возвращает МЕНЬШЕ записей, чем иннер.

upd поправил второй запрос, скопипастил и не заменил лефт на иннер
...
Изменено: 09.06.2022, 16:34 - Tammy Jo Saint Cloud
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60320
Горбатый ёж
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Tammy Jo Saint Cloud  09.06.2022, 16:31
[игнорируется]
давайте на секундочку представим, что формальная запись запроса и правда отображает тот порядок, в котором "физически" соединятся таблицы при выполнении запроса
Это что за древняя СУБД?
Или это любители хинтовать запросы?
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60321
basename
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Горбатый ёж  09.06.2022, 16:29
[игнорируется]
basename  09.06.2022, 16:29
[игнорируется]
Горбатый ёж  09.06.2022, 16:28
[игнорируется]
Хуяссе планы...
что с ними не так? )
А есть текстовый вариант?
В тектовом виде такое.

Оно? или что должно быть?
pasted_image.png
pasted_image.png
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60322
Tammy Jo Saint Cloud
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Горбатый ёж  09.06.2022, 16:34
[игнорируется]
Tammy Jo Saint Cloud  09.06.2022, 16:31
[игнорируется]
давайте на секундочку представим, что формальная запись запроса и правда отображает тот порядок, в котором "физически" соединятся таблицы при выполнении запроса
Это что за древняя СУБД?
Или это любители хинтовать запросы?
йобаный блядь в рот....
"ДАвайте ПРЕДСТАВИМ", для целей демонстрации
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60323
Горбатый ёж
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
basename  09.06.2022, 16:34
[игнорируется]
В тектовом виде такое.

Оно? или что должно быть?
Оно.
Но прям такое впечатление, что оптимизатору похую, что джойн, что лефт джойн.
Tammy Jo Saint Cloud  09.06.2022, 16:35
[игнорируется]
"ДАвайте ПРЕДСТАВИМ"
Это пагубный подход в обучении.
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60324
cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[игнорирует гостей]
Гесты и игнорируемые идут по CSS
Tammy Jo Saint Cloud  09.06.2022, 16:31
[игнорируется]
а вот для select * from Tab1 left join tab2 on a=b будет уже 2 варианта - идти по таб1 и лепить таб2 - или идти по таб2 и лепить к ней таб1
таким образом "Одинаково в обоих случаях" - немного неправильно.
Второй вариант может выполнятся или на коротких таблицах, когда оптимизатор решит, что использовать индексы тут нет нужды, или когда в первой таблице есть индекс по полю второй таблицы.

То есть.
Если у нас таблицы Post и Attachment, то в Post должен быть индекс по Attachment_Id. Не думаю, что кто-нибудь будет такой индекс делать
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60326
Tammy Jo Saint Cloud
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Горбатый ёж  09.06.2022, 16:38
[игнорируется]
Это пагубный подход в обучении.
нормальный подход, от простого к сложному, от частного к общему
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60328
Горбатый ёж
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cat2  09.06.2022, 16:39
[игнорируется]
Если у нас таблицы Post и Attachment, то в Post должен быть индекс по Attachment_Id.
В данной ситуации всё совсем наебарот.
cat2  09.06.2022, 16:39
[игнорируется]
Не думаю, что кто-нибудь будет такой индекс делать
Нормальный человек будет делать индекс на FK.
...
Рейтинг: 1 / 0
Нравится: PaNik
Господа базоёбы, скок сюды
    #60331
Tammy Jo Saint Cloud
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cat2  09.06.2022, 16:39
[игнорируется]
Второй вариант может выполнятся или на коротких таблицах, когда оптимизатор решит, что использовать индексы тут нет нужды, или когда в первой таблице есть индекс по полю второй таблицы.
што блядь?
Я могу показать как минимум несколько вариантов - с большими таблицами, с маленькими, с индексами, без индексов и так далее.

"второй вариант" показывает, что план выполнения иннер джойна может варьироваться по последовательности соединений
(лефт тоже может,но для простоты мы это не учитываем)
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60332
Tammy Jo Saint Cloud
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Горбатый ёж  09.06.2022, 16:41
[игнорируется]
Нормальный человек будет делать индекс на FK.
Очень сильно зависит от.
В некоторых случаях нормальный человек НИКОГДА не будет делать индекс на ФК
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60334
basename
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Горбатый ёж [игнорируется] 

Вот ещё вывод explain analyze

Как только в читабельном виде отобразить...

join
Цитата 
[игнорируется]
'-> Nested loop inner join (cost=473.95 rows=424) (actual time=0.235..3.066 rows=197 loops=1)\n -> Nested loop inner join (cost=325.38 rows=369) (actual time=0.154..1.790 rows=369 loops=1)\n -> Index lookup on v1_post using v1_post_user_id_idx (user_id=173) (cost=196.23 rows=369) (actual time=0.144..1.183 rows=369 loops=1)\n -> Single-row index lookup on v1_topic using PRIMARY (id=v1_post.topic_id) (cost=0.25 rows=1) (actual time=0.001..0.001 rows=1 loops=369)\n -> Index lookup on v1_attachment using v1_attachment_unq (post_id=v1_post.id) (cost=0.29 rows=1) (actual time=0.003..0.003 rows=1 loops=369)\n'
left join
Цитата 
[игнорируется]
'-> Nested loop left join (cost=419.06 rows=212) (actual time=0.137..2.520 rows=197 loops=1)\n -> Nested loop inner join (cost=344.79 rows=212) (actual time=0.130..1.888 rows=197 loops=1)\n -> Index lookup on v1_post using v1_post_user_id_idx (user_id=173) (cost=196.21 rows=369) (actual time=0.093..0.869 rows=369 loops=1)\n -> Filter: (v1_attachment.`name` is not null) (cost=0.29 rows=1) (actual time=0.002..0.003 rows=1 loops=369)\n -> Index lookup on v1_attachment using v1_attachment_unq (post_id=v1_post.id) (cost=0.29 rows=1) (actual time=0.002..0.002 rows=1 loops=369)\n -> Single-row index lookup on v1_topic using PRIMARY (id=v1_post.topic_id) (cost=0.25 rows=1) (actual time=0.003..0.003 rows=1 loops=197)\n'
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60335
Горбатый ёж
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Tammy Jo Saint Cloud  09.06.2022, 16:43
[игнорируется]
В некоторых случаях нормальный человек НИКОГДА не будет делать индекс на ФК
Случаи в студию.
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60337
cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[игнорирует гостей]
Гесты и игнорируемые идут по CSS
Tammy Jo Saint Cloud  09.06.2022, 16:43
[игнорируется]
cat2  09.06.2022, 16:39
[игнорируется]
Второй вариант может выполнятся или на коротких таблицах, когда оптимизатор решит, что использовать индексы тут нет нужды, или когда в первой таблице есть индекс по полю второй таблицы.
што блядь?
Я могу показать как минимум несколько вариантов - с большими таблицами, с маленькими, с индексами, без индексов и так далее.

"второй вариант" показывает, что план выполнения иннер джойна может варьироваться по последовательности соединений
(лефт тоже может,но для простоты мы это не учитываем)
Нихуя, блядь. Покажи реальные планы, когда будет соединение по второму варианту на обычной базе, а не придумывай хитрожопые способы выполнить запрос как можно медленнее.

Я тоже могу придумать способ, когда никаких индексов нет и INNER с OUTER будут выполнятся за одно и тоже время.
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60339
cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[игнорирует гостей]
Гесты и игнорируемые идут по CSS
Tammy Jo Saint Cloud  09.06.2022, 16:43
[игнорируется]
Горбатый ёж  09.06.2022, 16:41
[игнорируется]
Нормальный человек будет делать индекс на FK.
Очень сильно зависит от.
В некоторых случаях нормальный человек НИКОГДА не будет делать индекс на ФК
О, господи! Откуда этот придурок на нас свалился!
Дофига способов построить кривую базу, но вовсе не надо применять их всех!
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60342
basename
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
basename  09.06.2022, 16:44
[игнорируется]
Горбатый ёж [игнорируется] 

Вот ещё вывод explain analyze

Как только в читабельном виде отобразить...

join
Цитата 
[игнорируется]
'-> Nested loop inner join (cost=473.95 rows=424) (actual time=0.235..3.066 rows=197 loops=1)\n -> Nested loop inner join (cost=325.38 rows=369) (actual time=0.154..1.790 rows=369 loops=1)\n -> Index lookup on v1_post using v1_post_user_id_idx (user_id=173) (cost=196.23 rows=369) (actual time=0.144..1.183 rows=369 loops=1)\n -> Single-row index lookup on v1_topic using PRIMARY (id=v1_post.topic_id) (cost=0.25 rows=1) (actual time=0.001..0.001 rows=1 loops=369)\n -> Index lookup on v1_attachment using v1_attachment_unq (post_id=v1_post.id) (cost=0.29 rows=1) (actual time=0.003..0.003 rows=1 loops=369)\n'
left join
Цитата 
[игнорируется]
'-> Nested loop left join (cost=419.06 rows=212) (actual time=0.137..2.520 rows=197 loops=1)\n -> Nested loop inner join (cost=344.79 rows=212) (actual time=0.130..1.888 rows=197 loops=1)\n -> Index lookup on v1_post using v1_post_user_id_idx (user_id=173) (cost=196.21 rows=369) (actual time=0.093..0.869 rows=369 loops=1)\n -> Filter: (v1_attachment.`name` is not null) (cost=0.29 rows=1) (actual time=0.002..0.003 rows=1 loops=369)\n -> Index lookup on v1_attachment using v1_attachment_unq (post_id=v1_post.id) (cost=0.29 rows=1) (actual time=0.002..0.002 rows=1 loops=369)\n -> Single-row index lookup on v1_topic using PRIMARY (id=v1_post.topic_id) (cost=0.25 rows=1) (actual time=0.003..0.003 rows=1 loops=197)\n'
Господа, но вот видно тут, что left join выполняется быстрее почти в два раза!!!!!
...
Рейтинг: 0 / 0
Господа базоёбы, скок сюды
    #60348
cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[игнорирует гостей]
Гесты и игнорируемые идут по CSS
basename  09.06.2022, 16:54
[игнорируется]
basename  09.06.2022, 16:44
[игнорируется]
Горбатый ёж [игнорируется] 

Вот ещё вывод explain analyze

Как только в читабельном виде отобразить...

join
Цитата 
[игнорируется]
'-> Nested loop inner join (cost=473.95 rows=424) (actual time=0.235..3.066 rows=197 loops=1)\n -> Nested loop inner join (cost=325.38 rows=369) (actual time=0.154..1.790 rows=369 loops=1)\n -> Index lookup on v1_post using v1_post_user_id_idx (user_id=173) (cost=196.23 rows=369) (actual time=0.144..1.183 rows=369 loops=1)\n -> Single-row index lookup on v1_topic using PRIMARY (id=v1_post.topic_id) (cost=0.25 rows=1) (actual time=0.001..0.001 rows=1 loops=369)\n -> Index lookup on v1_attachment using v1_attachment_unq (post_id=v1_post.id) (cost=0.29 rows=1) (actual time=0.003..0.003 rows=1 loops=369)\n'
left join
Цитата 
[игнорируется]
'-> Nested loop left join (cost=419.06 rows=212) (actual time=0.137..2.520 rows=197 loops=1)\n -> Nested loop inner join (cost=344.79 rows=212) (actual time=0.130..1.888 rows=197 loops=1)\n -> Index lookup on v1_post using v1_post_user_id_idx (user_id=173) (cost=196.21 rows=369) (actual time=0.093..0.869 rows=369 loops=1)\n -> Filter: (v1_attachment.`name` is not null) (cost=0.29 rows=1) (actual time=0.002..0.003 rows=1 loops=369)\n -> Index lookup on v1_attachment using v1_attachment_unq (post_id=v1_post.id) (cost=0.29 rows=1) (actual time=0.002..0.002 rows=1 loops=369)\n -> Single-row index lookup on v1_topic using PRIMARY (id=v1_post.topic_id) (cost=0.25 rows=1) (actual time=0.003..0.003 rows=1 loops=197)\n'
Господа, но вот видно тут, что left join выполняется быстрее почти в два раза!!!!!
Когда ты показывал план для INNER в виде таблицы, то он был другим
...
Рейтинг: 0 / 0
25 сообщений из 242, страница 7 из 10
Форумы / MySQL [закрыт для гостей] / Господа базоёбы, скок сюды
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]