Доктрина

Если это ORM, то либо он идёт в жопу, либо ты с просьбой написать тебе запрос.
Потому что ORM не понимает SQL

Если это ORM, то либо он идёт в жопу, либо ты с просьбой написать тебе запрос.
Потому что ORM не понимает SQL

Привет. Допустим, есть таблица files с колонками one и two и индексами по каждой колонке отдельно.

Делая запрос select * from files where one = 1 or two = 2 мускул делает full table scan, не юзая ни один из индексов.

Это плохо, поэтому делаем union - select * from files where one = 1 union select * from files where two = 2 - и мускул юзнет два индекса. Неидеальный вариант, так как построение таких запросов в клиентском коде - неудобно. Не проблема мускула, конечно, но все же.

Конечно, запросы упрощены. В реальных больше условий, комбинированные индексы и where in из сабквери, но идея та же.

Вопрос: неужели оптимизатор мускула не может сам это разрулить и для первого запроса использовать union под капотом? Или я что-то таки делаю не так? Речь о версии 5.7, но подозреваю, что и в 8 ничего не поменялось.

Даже без ОРМ вложенный запрос более удачное решение задачи, так как пост обработка не нужна

OR стратегия реализуется в MySQL, она работает,
просто НЕ ВСЕГДА в таких случаях выгодно использовать индексы, а ты этого не учитываешь, и хочешь чтобы индексы были использованы безусловно.

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

Он же знает, что может использовать два индекса - остается только чуток преобразить запрос

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

Он же знает, что может использовать два индекса - остается только чуток преобразить запрос

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

Он же знает, что может использовать два индекса - остается только чуток преобразить запрос

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

Ребят, такой вопрос по теме баз данных: на поле повешен уникальный индекс, если делаем insert с неуникальным значением поля, получаем ошибку уровня БД.

И есть 2 подхода к обработки таких ситуаций:
1. Лазать в базу перед insert и смотреть, есть ли там уже запись с таким значением, если есть бросать исключение.
2. Вставлять данные без проверки, и парсить сообщение полученное от движка БД, бросать исключение.

Вы бы каким путем пошли?

Ребят, такой вопрос по теме баз данных: на поле повешен уникальный индекс, если делаем insert с неуникальным значением поля, получаем ошибку уровня БД.

И есть 2 подхода к обработки таких ситуаций:
1. Лазать в базу перед insert и смотреть, есть ли там уже запись с таким значением, если есть бросать исключение.
2. Вставлять данные без проверки, и парсить сообщение полученное от движка БД, бросать исключение.

Вы бы каким путем пошли?

1ый способ - вообще не подход.

Так что 2ой остаётся.

Но есть ещё 3ий -

Insert ..
On conflict ( update )
Returning ...

Не знаете что делат?