хороший вопрос, да

Может они какие-то за два считают

Ну везде 64 гига памяти, а в новых 128 значит будим считать за два

Правда что LEFT JOIN работает быстрее чем JOIN ?

просто join это inner join? вообще нет, inner самый быстрый

Правда что LEFT JOIN работает быстрее чем JOIN ?

не правда

У меня в команде некоторые почему то упорно пишут LEFT JOIN, утверждая что раз там внешние ключи все контролируют, то это безопасно, т.к. при выборке движок не будет делать дополнительных сравнений

У меня в команде некоторые почему то упорно пишут LEFT JOIN, утверждая что раз там внешние ключи все контролируют, то это безопасно, т.к. при выборке движок не будет делать дополнительных сравнений

вообще-то left или inner зависит от того, какие вы данные хотите вытащить. и результаты запроса будут разные

причем тут безопасность я хз

Вот представь что в таблице A все записи имеют FK на записи таблицы B. Тогда A LEFT JOIN B будет давать такой же результат как и A JOIN B

Но при этом скорость выборки в первом и втором случае якобы разная

это разные запросы и результаты

join = inner join

Сергей В конкретном случае с FK - одинаковые

но это только на первый взгляд))))

А дальше я выключу проверку, вставлю кучу ххрени, включу назад

и будет всем веселье

Вот представь что в таблице A все записи имеют FK на записи таблицы B. Тогда A LEFT JOIN B будет давать такой же результат как и A JOIN B

если fk у тебя null=False то надо писать inner join. он будет равен всегда left join. и inner будет быстрее если fk у тебя null=True то если ты напишешь inner join то никогда не получишь строк с зануленным fk

А дальше я выключу проверку, вставлю кучу ххрени, включу назад

Да, это понятно. Но вопрос именно про такую конфигурацию и про скорость выборки.

А дальше я выключу проверку, вставлю кучу ххрени, включу назад

ты не квлючишь назад, пока у тебя битые данные в таблице. БД контроллирует целостность

> и inner будет быстрее То есть это противоположно тому что у нас используется, значит надо будет бенчмаркать.

Сергей Наивный))))

@chebotarevp нигде в доке я не видел, чтобы при FK доп проверка выключалась, именно по той причине, что я описал. Может что-то и упустил конечно, но вряд ли

@chebotarevp нигде в доке я не видел, чтобы при FK доп проверка выключалась, именно по той причине, что я описал. Может что-то и упустил конечно, но вряд ли

еще раз - что за проверка?

если у вас fk null=True то вы на что-то всегда будете ссылаться

Сергей " т.к. при выборке движок не будет делать дополнительных сравнений"

ну еще strict mode on

Сергей " т.к. при выборке движок не будет делать дополнительных сравнений"

каких сравнений? еще раз сформулируй вопрос полностью плиз

Сергей я имел ввиду не удаление ключа, а просто foreign_key_checks

это к вопросу о "ты не квлючишь назад"

foregn_key_check это зашквар какой-то...

если у вас fk null=True то вы на что-то всегда будете ссылаться

Допустим что FK никогда не NULL и результаты JOIN и LEFT JOIN совпадают. Разработчики добросовестные и не пытаются похакать внешние ключи и отключить там что-то.

я вообще с постгресом работаю и таких проблем не знаю

не нужны проверки - не делай fk

я вообще с постгресом работаю и таких проблем не знаю

аааа, всё понятно.

не обязательный - сделай null=True

но inner join всегда быстрее по своей сути. и там и там

Ок, будем глубоко копать и бенчмаркать значит

Допустим что FK никогда не NULL и результаты JOIN и LEFT JOIN совпадают. Разработчики добросовестные и не пытаются похакать внешние ключи и отключить там что-то.

тогда всё равно левый джойн медленнее по идее. можно конечно провести тесты, но я сомневаюсь.

https://stackoverflow.com/questions/2726657/inner-join-vs-left-join-performance-in-sql-server

вот тут холиварят

А ничего, что это другая БД с другим оптимизатором?

принципы одни

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

там нет никакой магии же

такие простые вещи везде одинаково почти сделаны

да что вы...

вот это ваше почти одинаково потом боком выходит

реализация join в разных субд отличается, и в mysql она одна из самах говёных, если что

Реализация ВСЕГО я бы сказал отличается. Поиск, выборка, методология вставки, работы с дисокм и пр и пр.

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

и объединяет их только стандарт SQL

https://stackoverflow.com/questions/1810465/left-join-faster-or-inner-join-faster

Вот тут написано что может быть существенное различие

EXPLAIN EXTENDED - это что-то не из MySQL

Хм да, странно что тег mysql висит

EXPLAIN EXTENDED - это что-то не из MySQL

как много ты ещё не знаешь))))

или уже не знает. EXTENDED уже не нужен

накинулись!

Каюсь, забыл. Ибо последний раз встречал такое года 4 назад

но я не согласен, что в mysql какой-то не такой join. nested loop — классический алгоритм, чего с ним не так? hash джойнов нет? так есть batch key access, который по сути hash джойн "наоборот"

А уже деклассировать готовы?

я к тому, что многие ребята по привычке пишут EXPLAIN EXTENDED. а про это уже можно смело забывать. я вот уже сам почти забыл

оно почти никакой смысловой нагрузки не несёт все равно, почти всё можно увидеть в обычном explain, что до варнингов дело не доходит

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

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

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

привет. нет, нельзя. booking тоже такую фичу попросила: https://bugs.mysql.com/bug.php?id=75404

жаль, конечно, спасибо за инфу

жаль, конечно, спасибо за инфу

нажмите на "Affects me" в баге. они на это смотрят

Есть один столбец, в котором цифры, которые могут повторяться. Как сделать, чтобы для повторяющихся цифр во втором столбце была автоматическая нумерация?)

триггером.

но проще в код записи вынести

В phpmyadmin попроще никак?

Я думал это там должно называться как-то вроде "index", но видимо это совсем другое. Плохо, когда не разбираешься)

В phpmyadmin вообще ничего никак

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

Автоинкремент общий на таблицу, а не на столбец

окей

и он не зависит от удаления, этто просто счёттчик

То, что ты хочешь, делается кодом. Лучше кодом при изменении/добавлении. Хуже - кодом триггера

окей, хоть это и плохо. А ORACLE не спасёт в такой ситуации? Извиняюсь за гипотезу.

Оракл слишком накладный для таких простых манипуляций))))

Даже если бы и спас))))

Там кода - 5 строк

хех)) ну окей. Да и там наверное это тоже "триггеры" называется

есть такое, ну ладно

Лучше делать ппрямо в коде. Триггеры - намного хуже вариант

Хоття, вряд ли у теебя какой-то высоконагруженный проект, так чтто и они сойдут

То есть оптимальнее сделать SELECT запрос и послать INSERT, чем сделать INSERT с триггером?

То есть оптимальнее сделать SELECT запрос и послать INSERT, чем сделать INSERT с триггером?

да, только не забыть это дело обернуть в транзакцию с допроверкой (или униккальный ключ повесить) если у тебя теоритически возможно 2 вставки в единицу времени.

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

Второе) Благодарю :)

и сделать триггеры. НА простановку при инсерте и на пересортировку при апдейт/делет

оки

если тебе надо ппрроставить счётчик в кучи уже имеющихся записей - можешь копнуть в сторону сессионных переменных