Akina

Фактически выполняется сравнение двух длинных BINARY значений, причём при полнейшем отсутствии какого-никакого индекса. Чё б ему не тормозить?

В качестве решения предлагаю изменить тип поля на TEXT и добавить CHECK, а также индекс по значению.

CREATE TABLE test (
    id INT PRIMARY KEY,
    data TEXT CHECK (JSON_VALID(data)), 
    INDEX idx_data (data(100))   -- подогнать до разумного
);

DEMO (см. время выполнения запросов).

если в базе mysql (версия 5.7) часть таблиц в utf8mb4_general_ci, а другая в utf8_general_ci

:facepalm: Это не кодировки! Это COLLATION - набор правил для сравнения строковых значений.

Хотя справедливости ради следует сказать, что возможные COLLATION определяются использованным CHARACTER SET. А для показанных значений они различны - utf8mb4_general_ci указывает на UTF8MB4, а utf8_general_ci на UTF8, который для этой версии СУБД является алиасом UTF8MB3.

Влияет ли это как-то на производительность mysql?

Если выполняется сравнение строковых значений (либо иная обработка таких значений в пределах одного выражения) с указанными CHARSET/COLLATION - несомненно, поскольку перед сравнением как минимум одно из значений должно подвергнуться конвертированию CHARSET, а это ресурсы.

Если нет - то на производительность именно СУБД это влияет слабо. Заметное влияние будет при прогреве кэшей, а также в случае ну очень объёмных таблиц.

Плюс гарантированное преобразование финального набора записей при несовпадении CHARSET поля и клиентского соединения.

Например, так:

SELECT iw.id
FROM anything iw
LEFT JOIN status_anything si ON iw.id = si.anything_id
LEFT JOIN status s ON s.id = si.status_id
WHERE s.datum BETWEEN '2023-03-01' AND '2023-05-01'
GROUP BY 1
HAVING MIN(s.datum) > '2022-03-01'

SELECT good,                      -- выбрать идентификатор товара
       amount * unit_price AS `sum` -- и потраченную на него сумму
FROM Payments 
ORDER BY `sum` DESC;                -- отсортировать по убыванию суммы

WITH cte AS (
    SELECT a, b, c, COUNT(*) OVER (PARTITION BY a, c) cnt
    FROM table
)
SELECT a, b, c
FROM cte 
WHERE cnt > 1

Применительно к данной конкретной задаче:

• СУБД предназначена для хранения и обработки массивов данных.
  
• ЯП предназначен для обеспечения пользовательского интерфейса этого процесса и управления им.
  

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

Глобально: никакие.

Уровня БД либо отдельных объектов БД: данные - всё, кроме FILE; структура - CREATE TEMPORARY TABLES и (если используются хранимые объекты) EXECUTE.

Ну а далее - плюс дополнительные необходимые права, в зависимости от кривизны структуры и работы с базой.

DELIMITER - это не SQL-запрос, а команда клиента. PyMySQL - это не клиентская программа, а библиотека доступа, которая ни про какой DELIMITER не знает и знать не должна. Отсюда и ошибка. Опять же - нет никакого смысла напихивать в код лишнюю логику, без которой можно спокойно обойтись.

А если от всей лишней шелухи избавиться, то от всей логики останется один-единственный оператор. Который сделает использование DELIMITER и вовсе ненужным.

CREATE TRIGGER setUUID 
BEFORE INSERT ON users
FOR EACH ROW 
	SET NEW.uuid = COALESCE(NEW.uuid, UUID());

PRIMARY KEY - первичный ключ. Поле, комбинация полей либо выражение (последнее MySQL не поддерживает), которое не может быть NULL и не допускает дубликатов (уникально для каждой отдельной записи в пределах таблицы). Поддерживается путём создания соответствующего уникального индекса и наложением ограничения NOT NULL на все используемые в выражении поля. По факту - однозначно идентифицирует запись. Кроме того, в MySQL выражение первичного ключа является кластерным индексом. См. Индекс -> Уникальный индекс -> Первичный индекс.

CONSTRAINT - ограничение. Правило, которое не допускает создания записи, для которой значение выражения ограничения имеет значения FALSE (можно TRUE или NULL).

FOREIGN KEY - внешний ключ. Ограничение, которое требует, чтобы указанное выражение для текущей записи присутствовало среди значений указанного выражения референсной таблицы (допускается и внешний ключ на ту же таблицу). Точнее, чтобы такая проверка присутствия не возвращала FALSE (можно TRUE или NULL).

REFERENCES - определяет референсную таблицу и референсное выражение.

INSERT INTO - запрос, вставляющий новые записи в таблицу.

SELECT rule.id, rule.path, rule.content, rule.cat_id 
FROM rule
JOIN rule_options ON rule.id = rule_options.rule_id
WHERE rule_options.option IN (4670, 5492)
GROUP BY 1,2,3,4
HAVING COUNT(DISTINCT rule_options.option) = 2;