Akina

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

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

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. Вообще менять строковый атрибут на числовой - штука небезопасная. В приложении это может аукнуться - оно-то не в курсе...

Начните с определения группы адресов, подлежащих блокировке. Пропишите туда все подсети из RFC, кроме, возможно, мультикаста.

Затем первым создайте правило, согласно которому входящие пакеты WAN-интерфейса, адреса которых принадлежат этой группе, action=drop.

1) Как безопаснее и правильней писать имя таблицы и базы с кавычками или без кавычек . Если с кавычками то с двойными или одинарными.

В MySQL используется три разных типа кавычек.

1. Прямая кавычка '

Используется для обрамления литералов, требующих такого обрамления, а именно: строковые, даты-времени, JSON, компоненты имени учётной записи и пр. Подробнее см. Literal Values и Specifying Account Names

2. Обратная кавычка `

Используется для обрамления имён объектов (БД, таблиц, полей, имён функций/процедур и пр.).

Если имя объекта не содержит нелегитимных символов (подробнее см. Schema Object Names), не является служебным или зарезервированным словом (см. Keywords and Reserved Words), использование обратной кавычки опционально, иначе обязательно.

3. Двойная кавычка "

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

При включённом ANSI_QUOTES в SQL Mode указанные использования отменяются, и двойная кавычка используется для обрамления имён объектов (т.е. дублирует использование обратной кавычки).

ИТОГО с точки зрения безопасности:

- имена объектов ВСЕГДА обрамлять ТОЛЬКО обратной кавычкой
- литералы, требующие обрамления - обрамлять ТОЛЬКО одинарной кавычкой
- двойную кавычку использовать ТОЛЬКО как символ в составе литерала (строкового, JSON)

Нет, это явное нарушение RFC.

Адрес 192.168.40.40 относится к категории немаршрутизируемых в Интернете. Любой узел, если он получил пакет на этот адрес на интерфейсе с маршрутизируемым адресом, либо если он должен согласно своей таблице маршрутизации отправить его через интерфейс с маршрутизируемым адресом, должен отказать в маршрутизации (какое при этом применить правило - deny или drop,- не описано). В трассе имеется адрес 188.***.172, не принадлежащий какой-либо немаршрутизируемой сети - следовательно, в маршрутизации пакета должно было быть отказано.

А что бардак - таки да, это в порядке вещей. Вы поснифьте свой внешний адресок да посмотрите, сколько на него попадает "грязи" - удивитесь.

Для передачи из одной записи в другую никакие транзакции нафиг не нужны.

UPDATE tablename
SET balance = balance + CASE WHEN userid = @sender
                             THEN -@amount
                             ELSE @amount
                             END
WHERE userid IN (@sender, @receiver);

Для решения задачи может быть использован триггер.

Решение 1. Более простое, но может давать дубликаты в конкурентной среде.

CREATE TRIGGER tr_name
BEFORE INSERT
ON articles
FOR EACH ROW
SET NEW.image = CONCAT('catalog/blog-image/', COALESCE((SELECT 1 + MAX(SUBSTRING_INDEX(image, '/', -1)) FROM articles), 1), '.jpg');

DEMO

Решение 2.Устойчиво в конкурентной среде.

Создаётся опорная таблица генерируемых номеров:

CREATE TABLE image_counter (id INT AUTO_INCREMENT PRIMARY KEY);

Триггер использует таблицу для генерации:

CREATE TRIGGER tr_name
BEFORE INSERT
ON articles
FOR EACH ROW
BEGIN
    INSERT INTO image_counter VALUES (DEFAULT);
    SET NEW.image = CONCAT('catalog/blog-image/', LAST_INSERT_ID(), '.jpg');
    DELETE FROM image_counter;
END

DEMO

как сделать регистронезависимый поиск по longblob?

Регистрозависимость операций поиска/сравнения определяется применяемым COLLATION.
LONGBLOB имеет по умолчанию binary collation (например, utf8mb4_bin) - поэтому сравнение выполняется бинарное.
Для регистронезависимого текстового сравнения надо явно определить требуемый COLLATION в запросе. Типа

WHERE column COLLATE utf8mb4_0900_ai_ci LIKE 'pattern'

Если надо ещё и charset подкорректировать, то дополнительно использовать функцию CONVERT().

А если будем просто через LIKE то придет вот так (так не нужно): Иван, Ваня, Ивановы...

Нет. Отбор записей и их сортировка - две совершенно независимые операции.

SELECT word 
FROM words 
WHERE word LIKE '%$search%'
ORDER BY LOCATE($search, word), word