Akina

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

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

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

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

Начните с определения группы адресов, подлежащих блокировке. Пропишите туда все подсети из 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, не принадлежащий какой-либо немаршрутизируемой сети - следовательно, в маршрутизации пакета должно было быть отказано.

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