Akina

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

WITH cte AS (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY score DESC) rn
    FROM source_table
)
SELECT *
FROM cte
WHERE rn = 1
-- ORDER BY score DESC LIMIT nnn
;

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

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

CREATE TRIGGER trigger_name
EVENT ACTION ON table_name
FOR EACH ROW
BEGIN
    SET @trigger_name_table_name = CONCAT('executed, ', 'column_value=', NEW.column);
-- trigger action
    SET @trigger_name_table_name = NULL;
END;

Если в теле триггера определены EXIT хэндлеры - они тоже должны выполнять соответствующие сбросы.

будет ли использоваться индекс в запросе вида WHERE `field1` LIKE '_aa_a_'?

50/50 - или будет, или нет.

Однако если он будет использоваться, то не как индекс (сортированный список для выполнения index seek), а как компактная копия таблицы (как несортированный список для выполнения index scan).

Тем не менее профит от использования индекса таким образом может быть, и весьма значительный. Главным образом он определяется соотношением размера записи к размеру поля. И чем это соотношение выше, тем более вероятен профит.

SELECT p.name, p.id 
FROM products AS p
JOIN product_country AS cp ON cp.product_id = p.id 
WHERE cp.country_id IN (1,2)
GROUP BY 1, 2
HAVING COUNT(DISTINCT cp.country_id) = 2;

начать поиск элемента в таблице в БД с конца

В таблице нет ни начала, ни конца. Таблица - это несортированная куча. Если нужен какой-то порядок записей - его следует указать явно выражением сортировки.

как получить id последнего элемента в таблице?

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

Может, требуется тривиальное

SELECT *
FROM tablename
ORDER BY client_id IS NULL, hub_id IS NULL
LIMIT 1

?

SELECT DISTINCT data.*
FROM data
JOIN ( 
    SELECT 2 value 
    UNION ALL 
    SELECT 5 
    UNION ALL 
    SELECT 7
    ) criteria ON JSON_CONTAINS(data.jsonarray, CAST(criteria.value AS JSON))

1. Свитч и коммутатор - одно и то же.
   
2. Стекированные свичи следует воспринимать как один свич, просто собранный в двух корпусах.
   
3. Коммутатор уровня распределения - это просто коммутатор. Попадающий в озвученную категорию по своим характеристикам.
   

Так что задача, если разобраться, тривиальная - просто соединить два коммутатора.

Маска подсети занимает 16 бит, но в третьем октете есть бит, который не попадает под неё. Что мне делать с этим битом?

Задание - конечно, бредовое. 201.111.32.0/16 - это адрес хоста, а не сети, потому что адрес имеет единичные биты в области нулевых битов маски:

Host 11001001 01101111 00100000 00000000
Mask 11111111 11111111 00000000 00000000

Но к тому, что преподаватели сами безграмотны, мы уже привычные... посему попробуем интерпретировать задание так: выделение производить в подсети, в которой находится узел 201.111.32.0/16 (это подсеть 201.111.0.0/16), выделяемые подсети должны располагаться не ранее указанного адреса узла, и допускать количество хостов не менее заданного.

Начать надо с определения минимальной маски конечной подсети.

Хостов Маска
 170     /24
 590     /22
1500     /21
 800     /22
 254     /24

Далее, чтобы заполнять диапазон оптимальным образом, надо выделять подсети так, чтобы они занимали наиболее широкую возможную подсеть полностью либо по максимуму. Т.е. берём заданную границу host 201.111.32.0 mask /16 и начинаем "откусывать" требуемые подсети. С целью минимизации расхода адресного пространства мы на каждом шагу распределяем самую "широкую" из подсетей, которая укладывается в текущее место.

Сначала определяем максимальную маску для данного узла. Это будет маска /19:

Host 11001001 01101111 00100000 00000000
Mask 11111111 11111111 11100000 00000000

Значит, с данного адреса мы можем сразу распределить подсеть 3. Она будет иметь адрес 201.111.32.0/21 и занимать диапазон адресов 201.111.32.0 - 201.111.39.255, последний адрес является бродкастом.

Теперь мы распределяем оставшиеся подсети с первого свободного после уже выделенной подсети адреса 201.111.40.0. Максимальная маска для этого узла - /21. Соответственно распределяем здесь самую крупную из оставшихся подсетей. Это подсеть 2. Она будет иметь адрес 201.111.40.0/22, займёт диапазон адресов 201.111.40.0-201.111.43.255.

Далее мы распределяем оставшиеся подсети с первого свободного после уже выделенной подсети адреса 201.111.44.0. Максимальная маска для этого узла - /22. Соответственно распределяем здесь самую крупную из оставшихся подсетей. Это подсеть 4. Она будет иметь адрес 201.111.44.0/22, займёт диапазон адресов 201.111.44.0-201.111.47.255.

Далее мы распределяем оставшиеся подсети с первого свободного после уже выделенной подсети адреса 201.111.48.0. Максимальная маска для этого узла - /20. Соответственно распределяем здесь самую крупную из оставшихся подсетей. Это подсеть 1. Она будет иметь адрес 201.111.48.0/24, займёт диапазон адресов 201.111.48.0-201.111.48.255.

Далее мы распределяем оставшиеся подсети с первого свободного после уже выделенной подсети адреса 201.111.49.0. Максимальная маска для этого узла - /24. Соответственно распределяем здесь самую крупную из оставшихся подсетей. Это единственная оставшаяся подсеть 5. Она будет иметь адрес 201.111.49.0/24, займёт диапазон адресов 201.111.49.0-201.111.49.255.