Помогите с MySQL запросом пожалуйста
записаны они в нем в таком виде
catid,catid,catid,catid,catid,catid
то есть например
1,5,12,10
Как выбрать из таблицы все страницы с категорией только 5 например?
P.S. зачем мучить LIKE если есть IN () я тоже не понял...
Поясни про in() ... не нашел...
Т.е. строку |12||14||15| разбиваем на табицу (id_parent, number), где number и является числом из мн-ва 12,14,15. Теперь выборка будет с условием WHERE number IN(12,14), а не LIKE.
+ как вы собираетесь удалять элементы строки? Чтоли каждую строку выбирать, искать в ней подстроку, удалять? Ну это изврат гигантский.
все просто
Апдейт все равно идет по каким то ключам, вот сделать соотв. заранее темповую табличку, в ней приготовить данные для апдейта и потом обновить одним запросом из темповой таблички таргет-табличку.
Ну что это за ответ, ага? Так и обновлять как все обновляют... Все - это кто?
95 процентов населения, как Кот любит говорить?
У вас есть таблица с данными. В ней 10 000 строк. Вы хотите обновить их все. Вероятно, по какому то бизнес правилу? (типа - для каждой строки которая имеет quantity < 10 поставить статус в FAILED etc) Что это за правила? полная логика обновления. Какая она, эта логика?
Именно, и если не ошибаюсь для мускуля это абсолютно идентичные записи. т.е. id IN (1,2,3) интерпритируется как (id=1 or id=2 or id=3).
Т.е. сильно IN-ом увлекатся не стоит
при JOINе, мускуль создаёт временнут таблицу и записывает туда объединяемые таблицы ПОЛНОСТЬЮ, или только те записи, которые соответствуют условию?
Вопрос к тому, насколько болезненно для мускуля джоинить данные из таблиц с 100к+ записей?
Т.е. сильно IN-ом увлекатся не стоит
Почему это не стоит? Или он в мускуле реализован криво?
Например, в некоторых других СУБД - обычная нормальная практика писать
where sys_id in (select id from table_name where...) etc. с подзапросами. Которые могут возвращать много уникальных значений. Такии вещи, как разворачивание подзапросов и трансформации IN во что-то оптимизатор в СУБД должен делать.
при JOINе, мускуль создаёт временнут таблицу и записывает туда объединяемые таблицы ПОЛНОСТЬЮ, или только те записи, которые соответствуют условию?
Я не знаю сходу, но вероятно можно быстро нагуглить. Вам для саморазвития или для работы приложения это важно? Я бы скорее мерил какие то конкретные вещи типа времени выполнения запроса / план его / потребление памяти.
Вопрос к тому, насколько болезненно для мускуля джоинить данные из таблиц с 100к+ записей?
Зависит от того, какой логический джойн нужен (inner, left, rigth..) и какой алгоритм объединения используется (hash join, nexted loops, sorted merge), по каким полям, сколько их, какие используются предикаты (только == и != или еще <, >, LIKE, IN), разумеется - какие индексы на таблицах, есть ли на таблицах партишенинг (если есть - совпадает ли он на таблицах, достигается ли Partition Pruning и прочее).
Если вообще, джойн таблиц по 100к записей - при правильном использовании индексов, отсекающих предикатах и грамотной структуре базы вообще ноль даже на слабом железе (Вот таблицу в которой скажем, 5-10 миллиардов записей - надо джойнить крайне внимательно). Но если у вас таких запросов идет по 10k в секунду - тогда я не знаю :)
Короче, запросы план запросов и таблиц в студию.
WHERE id = 5 идентично WHERE 5 = id. Из этого следует, что не нужно писать WHERE (id = 5 OR otherId = 5), достаточно 5 = (id OR otherId);
Сорь за флуд )
таким способом.