Akina

Удалить только самые старые (оставить все остальные)

DELETE t1
FROM table t1
LEFT JOIN table t2 ON t1.dup_column = t2.dup_column
                  AND t1.time_column > t2.time_column
WHERE t2.time_column IS NULL

Оставить только самые новые (удалить все остальные)

DELETE t1
FROM table t1
JOIN table t2 ON t1.dup_column = t2.dup_column
             AND t1.time_column < t2.time_column

Суть задачи удалить все дубли квартир приходящие с разных импортов, по умолчанию считаем что последний файл импорта актуальный

Создай уникальный индекс по номеру квартиры (после чистки, само собой) и используй не INSERT INTO, а REPLACE INTO.

Задача недоопределена.

Например, под термином CSV можно понимать как файл единой структуры (причём как plain-структуры, так и с сериализованными данными), так и несколько конкатенированных (как в процессе вывода, так и явно по окончании вывода) файлов, каждый из которых имеет свою структуру (да ещё и дополнительная информация там может храниться, вроде имён таблиц и имён/типов полей).

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

А так - вот не вижу ну никакой проблемы. Лишь бы на той стороне обработки этого CSV был код, который правильно интерпретирует данные и корректно разложит их обратно по таблицам. Причём если идёт речь о создании универсального инструмента, то только в этом самом последнем моменте (вывод результата запроса в CSV) могут возникнуть хоть какие-то сложности. Остальное просто и плоско, как блин.

Я не знаю их архитектуру и название таблиц заранее

Хотя вот ещё одна точка, где могут возникнуть сложности. Теоретически все СУБД должны бы поддерживать INFORMATION_SCHEMA, всё же стандарт как бы описывает - и всё равно не всё там просто и очевидно.

Что-то уж больно на бред воспалённого сознания похоже.

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

Но можно начать и с обычных чисел Фибоначчи.

В случае рекурсивной реализации ряда Фибоначчи это условие n<2 и специальное значение 1. Смешно, но совершенно такие же и условие, и спецзначение у Хофштадтера.

SELECT *
FROM table
WHERE to_char(dob, 'MMDD') = '0216'

Эти операции может, и приоритетны, но за пределами MySQL. Вот там и решайте эту проблему.

В MySQL Community Server нет ничего подобного в принципе. А вот в Enterprise имеется MySQL Enterprise Thread Pool, умеющий приоритезировать соединения (не запросы).

В принципе можно ещё покопаться в MySQL proxy и аналогичных. Может, и там что сыщется.

Проблема заключается в том, что при нескольких одновременных запросах ...

При выполнении нескольких запросов одновременно (параллельно) каждый запрос должен выполняться в своём собственном соединении.

MySQL в принципе не знает про параллельные запросы в одном соединении - пока выполнение запроса не завершится и не будет отдан результат, соединение просто не взаимодействует с потоком ввода.

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

Можно ли как-то конвертировать строку с числами перечислением через запятую?

Можно. Но вот получить набор критериев для применения в WHERE IN - нельзя.

В принципе задача в нынешнем виде (если не делать как нужно, что описано в ответе FanatPHP) имеет минимум пару решений.

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

Можно добавить скобки, превратив строковый список в JSON-массив, и распарсить его на отдельные элементы функцией JSON_TABLE(). Но и этот метод быстродействием не отличится.

Так что срочно забывайте эту дурь с GROUP_CONCAT() и используйте нормальный JOIN.

По показанным данным и тому, что удалось выудить из описания и комментариев, мне кажется, что достаточно для каждой группы вернуть одну запись с максимальным в группе значением quantity. Это делается запросом

WITH cte AS (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY group_id ORDER BY quantity DESC) rn
    FROM tablename
)
SELECT *
FROM cte
WHERE rn = 1;

Запрос предполагает, что для всех записей группы значение minimum одинаково. Если это не так - использовать ORDER BY quantity>minimum DESC, quantity DESC.

Запрос предполагает, что в группе нет дубликатов по quantity. Если это не так - вернётся случайный из дубликатов с максимальным значением поля. Если нужен определённый из них - расширить соотв. образом ORDER BY.

Если версия MySQL старая и не поддерживает ни CTE, ни оконные функции - использовать эмуляцию ROW_NUMBER() на базе UDV в подзапросе.

Что такое instance

Вообще Instance - это экземпляр. В данном случае экземпляр MySQL-сервера.

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

PS. Операционка, в которой все они одновременно работают, тоже может быть Instance, но только уже OS instance, если она - одна из нескольких виртуализованных операционных систем, одновременно работающих на одном хосте в рамках одного VMM.

как это настроить?

Настройка MySQL-сервера на то, какие каналы (IP, named pipe, shared memory), а для IP - с какими настройками (номер порта), выполняется через конфигурационные файлы сервера. Где они, какие имеют имена, какие параметры следует устанавливать и прочее - читай в Reference Manual.

Использовать 2 копии таблицы. Одну для получения даты по заданному UUID, вторую для выборки записей.

SELECT t1.*
FROM table t1
JOIN table t2 ON t2.uuid = @uuid1 
             AND t1.createdAt > t2.createdAt
ORDER BY createdAt ASC LIMIT 100

Надо указывать полный путь.

select jsonb_value,
       jsonb_set(jsonb_value, '{requisites,kpp}', '"777"', false)
FROM test;

https://dbfiddle.uk/?rdbms=postgres_12&fiddle=3cfb...

PS. Вообще менять строковый атрибут на числовой - штука небезопасная. В приложении это может аукнуться - оно-то не в курсе...