Akina

SELECT UserID, t1.CountMessage-t2.CountMessage
FROM daily_exp_snapshots t1
JOIN daily_exp_snapshots t2 USING (UserID)
WHERE t1.date_added >= CURRENT_DATE
  AND t1.date_added < CURRENT_DATE + INTERVAL 1 DAY
  AND t2.date_added >= CURRENT_DATE - INTERVAL 1 DAY
  AND t2.date_added < CURRENT_DATE

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

call_id, где есть больше одного значение value

SELECT call_id
FROM tablename
GROUP BY call_id
HAVING COUNT(DISTINCT value) > 1

можно порт сделать так чтобы,порт был и tagged (тегированным -определенным vlan-ом) и аксессом ?

Можно, делай.

На одном порте может быть сколько угодно тегованных VLAN, и не более одного нетегованного. Причём одновременно. Исключение - вторым нетегованным может быть Voice VLAN.

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

SELECT client
FROM ( SELECT DISTINCT client
       FROM Dep
     UNION ALL
       SELECT client_id
       FROM Contact ) total
GROUP BY 1
HAVING COUNT(*) = 1

WITH RECURSIVE
cte AS ( SELECT *, 1 level
         FROM category 
         WHERE id = $category_id
         UNION ALL
         SELECT cat.*, cte.level + 1
         FROM category cat
         JOIN cte ON cat.id = cte.parent_id )
SELECT *
FROM cte
ORDER BY level;

Для древних версий:

SELECT CONCAT_WS('=>', c1.id, c2.id, c3.id, c4.id, c5.id) path
FROM category c1
LEFT JOIN category c2 ON c1.parent_id = c2.id
LEFT JOIN category c3 ON c2.parent_id = c3.id
LEFT JOIN category c4 ON c3.parent_id = c4.id
LEFT JOIN category c5 ON c4.parent_id = c5.id
WHERE c1.id = $category_id

Ну соответственно подрихтовать до нужного вида выходного набора.

Запрос неверен синтаксически.
1. Каждый JOIN обязан иметь свой ON. Это только MySQL/MariaDB лояльно относится к таким вещам.
2. Литералы даты должны быть обрамлены кавычками - это как минимум. А кроме того, формат литерала даты должен чётко соответствовать таковому для используемой СУБД - возможно, даже нужно использовать функцию преобразования строкового значения в дату.
3. Формально - запрос должен быть завершён символом точки с запятой.

Запрос неверен логически.
1. Отсутствует связь между заказом/менеджером и покупателем.
2. Отсутствует подсчёт общей суммы заказов покупателя.
3. Не предусмотрен вариант, когда у покупателя посередь периода сменился менеджер (менеджеры увольняются, да...). Впрочем, он не предусмотрен и в задании...
4. Задание требует "с 01.01.2013", т.е. включительно, а в условии отбора используется строгое неравенство.

Всё остальное - правильно.

Постройте сводную таблицу, делов-то...

Пример с линейной интерполяцией.

WITH 
cte1 AS ( SELECT t1.ts, t1.val,
                 t2.ts ts_before, t2.val val_before,
                 t3.ts ts_after, t3.val val_after
          FROM test t1
          JOIN test t2 ON t1.ts >= TIMESTAMP(t2.ts, @delta)
          JOIN test t3 ON t1.ts <= TIMESTAMP(t3.ts, @delta) ),
cte2 AS ( SELECT *, 
                 ROW_NUMBER() OVER (PARTITION BY ts ORDER BY ts_before DESC) rn_before, 
                 ROW_NUMBER() OVER (PARTITION BY ts ORDER BY ts_after ASC) rn_after
          FROM cte1 )
SELECT ts,
       val,
       ts_before,
       val_before,
       ts_after,
       val_after,
       CASE WHEN val_after = val_before
            THEN val_before
            ELSE val_before + (val_after - val_before) / TIMESTAMPDIFF(SECOND, ts_after, ts_before) * TIMESTAMPDIFF(SECOND, ts, TIMESTAMP(ts_before, @delta)) 
            END val_approximated
FROM cte2 
WHERE ts > '2021-01-02'
      AND rn_before = 1
      AND rn_after = 1

DEMO fiddle с некоторыми пояснениями.

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

Не имел дела раньше с оконными функциями в MySQL.

А придётся. И не просто "иметь дело", а хорошо изучить, до полного понимания.

Поделить на элементы, отбросить ненужные, собрать обратно:

WITH cte AS (SELECT 1 id, CAST('[12, 13, {"12": 123} ]' AS JSON) sort)
SELECT cte.id, JSON_ARRAYAGG(jsontable.element) sort
FROM cte
CROSS JOIN JSON_TABLE(cte.sort,
                      '$[*]' COLUMNS (element JSON PATH '$')) jsontable
WHERE jsontable.element != CAST('{"12": 123}' AS JSON)
GROUP BY cte.id

https://dbfiddle.uk/?rdbms=mysql_8.0&fiddle=405ff0...

PS. Сравнение объектов JSON - занятие неблагодарное. В более сложных случаях не пройдёт, даже JSON_OVERLAPS() может не спасти. Возможно, использование строковых функций на строковом представлении JSON более правильное решение.

Любая СУБД имеет достаточно мощную систему контроля целостности и непротиворечивости данных. Эта система работает, используя набор правил контроля, описанных в структуре БД, и жёстко следит за тем, чтобы ни одно из правил не было нарушено.

Внешний ключ - это как раз такое правило. Сформулировано оно так: в данном поле таблицы не может храниться значение, которое не присутствует в той таблице, на которую ссылается внешний ключ (rонечно, в зависимости от конкретного текста ссылки внешнего ключа и самого поля тут возможны варианты - например, в этом поле может храниться не только значение, присутствующее в ссылочной таблице, но и NULL). И, имея такое правило, СУБД ни при каких условиях не позволит его нарушить. Любая попытка вставить запись со значением, которого нет в ссылочной таблице, приведёт к ошибке. Любая попытка изменить существующее значение на такое, которого "там" нет - приведёт к ошибке. То же касается и "второй" стороны, СУБД не позволит изменить значение в ссылочной таблице или удалить его (потому что записи в нашей таблице при этом "потеряют" ссылку) - такая попытка корректировки приведёт к ошибке.