Как удалить запись в таблице MySQL по трём параметрам?

Question

[My1Name]

Есть следующий MySQL запрос на удаление:

DELETE FROM table_name WHERE col_1=val_1 AND col_2=val_2 ORDER BY type=val_3 LIMIT 1

Как правильно удалить запись в таблице по трём параметрам или по UNIQUE INDEX (col1, col2, col3)?

Comments

[Everything_is_bad]

Лучше добавь суррогатный ключ чтобы не было таких проблем.

[My1Name]

Everything_is_bad,
UNIQUE INDEX key (col1, col2, col3)
Как написать запрос на удаление?)

[Everything_is_bad]

UNIQUE INDEX key (col1, col2, col3)

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

ORDER BY type=val_3

что это значит? как по твоему представлению это должно работать?

[My1Name]

Everything_is_bad,

ORDER BY type=val_3

что это значит?

Сортировать по "type"

[Everything_is_bad]

My1Name,

Сортировать по "type"

сортировать это просто ORDER BY type, а что значит именно со связкой type=val_3?

[Ипатьев]

Я не очень понял вопрос.
Не спрашиваете же вы, как вместо двух условий в запросе сделать три?

[Everything_is_bad]

Ипатьев, было бы очень смешно если это так

[Ипатьев]

Everything_is_bad, да, нам всем уже очень смешно.
Поэтому потрудитесь объяснить, что мешает вам добавить третье условие.

И в целом объяснить суть своих проблем.
Потому что ответ на вопрос, как удалить по трем параметрам как бы очевиден: удалять надо по трем параметрам, а не по двум

[Everything_is_bad]

Ипатьев, не тому отвечаешь)

[My1Name]

Ипатьев, как сгруппировать три параметра в один UNIQUE KEY и потом удалять по этому ключу ?

[Ипатьев]

ДОБАВИТЬ в запрос AND col3=value

[Everything_is_bad]

My1Name, так же как ты сейчас сделал where c двумя полями, к этому условию добавить третье, проблема так и не понятна, а UNIQUE INDEX это индекс, а не поле с которым работают.

[Руслан Федосеев]

а чем это отличается от варианта WHERE col_1=val_1 AND col_2=val_2 AND col_3=val3
Вы серьезно считаете, что порядок удаления записей ( ORDER by ...) имеет значение?

[Akina]

Руслан Федосеев,

Вы серьезно считаете, что порядок удаления записей ( ORDER by ...) имеет значение?

При наличии в запросе LIMIT - увы, да. Имеет. https://dbfiddle.uk/-Ml3LdqG

My1Name,

как сгруппировать три параметра в один UNIQUE KEY

Создать уникальный индекс по соотв. выражению.

удалять по этому ключу ?

Удалять по ключу - несуществующее понятие. Удалять можно по некоему критерию (который в т.ч. может быть и комбинацией из нескольких других, более простых, критериев), в качестве какового может быть как выполнение некоего условия отбора, так и положение записи при некоей сортировке (последнее поддерживается далеко не всеми СУБД).

[Руслан Федосеев]

прошу прощения, limit то я и не заметил )

[My1Name]

Akina,

Удалять по ключу - несуществующее понятие.

но ведь MySQL создаёт ещё одно поле, если мы создаём UNIQUE KEY... К нему можно как-то обратиться? Типа:

DELETE FROM table WHERE key VALUES(col1, col2, col3)

??

[Ипатьев]

Не создаёт MySQL никакое поле. И к нему нельзя обратиться

[Vitsliputsli]

My1Name, а в чем собственно проблема? чем мешает удаление по 3 полям? зачем хочется писать только 1 условие?

[My1Name]

Vitsliputsli, Проектируется большая БД (в теори, высоконагруженная частотой запросов) с множеством разных таблиц. Необходимо оптимизировать скорость доступа к одной записи.

[Ипатьев]

My1Name, ну если все вокруг имбецилы, то попробуйте им объяснить, при чем тут скорость доступа, если вопрос был про условие

[Vitsliputsli]

My1Name,

Проектируется большая БД (в теори, высоконагруженная частотой запросов) с множеством разных таблиц.

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

Необходимо оптимизировать скорость доступа к одной записи.

Тогда обращайтесь к этой записи по primary key, а не через индексы. Либо суррогатный ключ, как уже предлагали, либо составной ключ (и то, в этом случае надо посмотреть какие типы данных у этих полей).

[My1Name]

Vitsliputsli,

Тогда обращайтесь к этой записи по primary key

нету primary key в этой таблице. Есть дубликаты...

не выдумывайте искусственных проблем, постройте обычную БД в соответствии с реляционной теорией

Это вы выдумываете.

Либо суррогатный ключ, как уже предлагали

Ваши предложения остались в рамках вашей теории. К данному вопросу нет ни одного ответа.

[Ипатьев]

My1Name, потому что на понятный вопрос я уже ответил, два часа назад.

[My1Name]

Ипатьев, правильный ответ, а точней ход мыслей, написал Everything_is_bad. Но, ответ с использованием суррогатного ключа - он (или она) так и не написал.

[Ипатьев]

Как я писал выше, ответ с использованием суррогатного ключа не существует.
Обращение к строке в таблице происходит по полям, а не "по ключу".
Перед тем как называть других имбецилами, неплохо бы сначала самому узнать, как работают элементарные запросы

[Vitsliputsli]

My1Name,

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

Это искусственная проблема, т.к. проблемы по факту нет, но вы чтото хотите решить. Оптимизация это всегда жертва чемто ради чегото, поэтому нужно знать, что мы хотим улучшить, и чем готовы пожертвовать.
В общем случае, обращение по первичному ключу всегда быстрее, чем по полям, хоть с индексом, хоть без. Первичный ключ есть всегда, то что вы не создали соответствующее поле, просто лишает вас возможности к нему обратиться, MySQL создаст его сам.
А вопросы оптимизации чаще всего решаются проектированием БД, а не вставкой в запрос магической фразы "сделай все хорошо". Поэтому не будете менять структуру, не получите изменений.

[My1Name]

Vitsliputsli,

Первичный ключ есть всегда

Что вы подразумеваете под первичным ключом?
Говорите пожалуйста языком программирования. Я сам философ не хуже вас... Вы имеете ввиду PRIMARY KEY, UNIQUE KEY или что вы подразумеваете?

[Akina]

offtop

@My1Name,

Проектируется большая БД (в теори, высоконагруженная частотой запросов)

нету primary key в этой таблице.

Я плакаль! За проектирование БОЛЬШОЙ и, по расчётам, ВЫСОКОНАГРУЖЕННОЙ, базы данных берётся человек, которому глубоко плевать на нормализацию, который вообще не анализировал предметную область и не собирался строить ER-диаграмму (и вообще не факт, что он знает, что это такое)... но его почему-то очень сильно волнует производительность одного сильно частного запроса.

По всем ощущениям автор - полный и абсолютный в этой области дилетант. А результат его работ предсказуем, и (если он срочно не перестроится и не начнёт глубоко изучать теорию) скорее всего будет весьма плачевен.

[My1Name]

Ипатьев,

Как я писал выше, ответ с использованием суррогатного ключа не существует

Почему INSERT IGNORE по UNIQUE INDEX работает без проблем? Оно же делает фактически тоже самое...

В крайнем случае, создают дополнительное поле, которое содержит комбинированную информацию по нескольким полям ("суррогатный ключ"). И тогда это поле может выступать как PRIMARY KEY. Однако, мне этот вариант не очень нравится... Ключ под это поле нужно как-то сжимать. И я думаю MySQL это знает лучше меня.

Например, если у меня два поля типа INT (long) а третье CHAR, то чтоб их скомбинировать (тупо) нужно создать поле VARCHAR как минимум в три раза больше :/

[Akina]

My1Name,

Что вы подразумеваете под первичным ключом?
Говорите пожалуйста языком программирования.

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

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

[Ипатьев]

My1Name, вы какой-то бред несёте. При чем тут insert? При чем тут какое-то комбинированное поле? У вас был детский вопрос, как указать в запросе не два поля, а три три. Вам ответили.
У вас был дурацкий вопрос, как удалить "по ключу". Вам ответили, что такого синтаксиса в SQL нет. БД сама использует ключи для оптимизации запросов, а к синтаксису они не имеют отношения.
Теперь у вас какие-то нелепые фантазии про первичные и суррогатные ключи. Вы считаете первичный ключ "философским понятием" и у вас опять нелепая фантазия про то, что для суррогатного ключа надо создавать зачем-то отдельное поле.

Не надо выставлять свое невежество напоказ так явно.

[Everything_is_bad]

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

Answer 1

[Ипатьев]

Чтобы правильно удалить запись в таблице по трём параметрам, надо указать все три параметра в условии WHERE

DELETE FROM table_name WHERE col_1=val_1 AND col_2=val_2 AND col_3=val_3

Не два, не пять, не десять, а ровно три параметра.