Akina

MySQL не поддерживает многотабличный INSERT.

Варианты:

1. Хранимая процедура
   
2. Триггер (но нужно решать проблему с передачей параметров для остальных таблиц)
   

mysql думает что в файле отсутствует группа, но там все есть

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

пробовал ставить кодировку ANSI

Должен быть чистый ASCII.

В простом варианте:

SELECT 500 queue, operator, os.avg_os, ss.avg_ss
FROM ( SELECT operator,AVG(valuation) avg_os
       FROM oper_survey 
       WHERE queue = '500' AND `date` BETWEEN '2021-06-01' AND '2021-06-16' 
       GROUP BY operator ) os
JOIN ( SELECT operator, AVG(valuation) avg_ss
       FROM service_survey 
       WHERE queue = '500' AND `date` BETWEEN '2021-06-01' AND '2021-06-16' 
       GROUP BY operator ) ss USING (operator)

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

SELECT 500 queue, operator, COALESCE(os.avg_os, 0) avg_os, COALESCE(ss.avg_ss, 0) avg_ss
FROM ( SELECT operator FROM oper_survey WHERE queue = '500'
       UNION 
       SELECT operator FROM service_survey WHERE queue = '500' ) op
LEFT JOIN ( SELECT operator,AVG(valuation) avg_os
            FROM oper_survey 
            WHERE queue = '500' AND `date` BETWEEN '2021-06-01' AND '2021-06-16' 
            GROUP BY operator ) os USING (operator)
LEFT JOIN ( SELECT operator, AVG(valuation) avg_ss
            FROM service_survey 
            WHERE queue = '500' AND `date` BETWEEN '2021-06-01' AND '2021-06-16' 
            GROUP BY operator ) ss USING (operator)

SELECT users.name AS username,
       count(orders.id) AS orders_count 
FROM users
JOIN orders ON orders.user_id=users.id
GROUP BY users.name

Если нужно вывести и пользователей, у которых нет заказов, с нулевым количеством, то использовать LEFT JOIN.

PS. Запрос из текста вопроса тоже корректен и должен дать правильный результат. Причём с 50% вероятностью он будет преобразован в мой (точнее, оба дадут один и тот же план выполнения). Остальные 50% - на то, что он будет выполнен итерационно (и тогда скорее всего просто будет выполняться дольше).

Правильно ли понимаю, что в случае отказа слейва на какое-то условное кол-во времени за которое mysql-bin.log заротейтится при достижении условных 100М, то при восстановлении слейв сервера, данные, которые находятся уже в архивном логе не будут записаны?

Нет, неправильно.

max_binlog_size устанавливает размер ОДНОГО файла лога. Когда указанный размер достигнут, создаётся новый, и запись идёт уже в него. А старый никуда не девается, и будет нормально передан на слейв, когда его функционирование восстановится.

Погуглил, вроде как все советуют такое решение:

Дерьмо. Забудь.

Есть большая БД на 50гб, и стоит задача удалить дубли в одной из таблиц.
[skipped]
Но проблема в том что в других таблицах есть связи через внешние ключи с моей основной.

Порядок действий.

Запрос 0. Выполнить полное резервное копирование. Убедиться, что полученный бэкап валиден.

Запрос 1. Для каждого набора дубликатов изменить реферальные значения в связанных таблицах, присвоить значению реферального поля значение, взятое из записи с минимальным (или максимальным) значением первичного индекса. Выполняется отдельно для каждой таблицы, имеющей внешний ключ в целевую.

Запрос 2. Удалить все записи-дубликаты, кроме имеющих минимальное (или максимальное) значение первичного индекса.

DEMO fiddle

Шаблон.

SELECT product.id
FROM product
INNER JOIN product_property
INNER JOIN property
WHERE property.value IN ( {values list} )
GROUP BY product.id
HAVING COUNT(DISTINCT property.value) = {distinct values count}

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

Мне нужно загнать всё это дело в MySQL. Какие наиболее оптимальные способы для этого есть?

Оптимальный - положить этот файл туда, куда может дотянуться MySQL. Импортировать, используя LOAD DATA INFILE, во временную таблицу. Несложным запросом распарсить в рабочие таблицы (как я понимаю, хоть весь файл и невалиден как JSON, но каждая отдельная строка файла есть JSON валидный). И прибить временную таблицу.

На всё про всё три запроса. Если очень хочется, можно их выполнить и через php, конечно. Но я бы затолкал их в хранимую процедуру (особенно если задача импорта обновлённых данных будет регулярная) и вызывал её - тогда вообще один запрос CALL proc_name;.

А можно и в один запрос уложиться, если использовать LOAD DATA INFILE с препроцессингом. Тогда и валидность JSON на строку неважна =- лишь бы формат данных в строке не плавал от одной строки к другой.

А гонять 18 гектар с диска в PHP, а потом от PHP к MySQL - ну несерьёзно.

PS. Загрузка с использованием LOAD DATA INFILE весьма нетребовательна к объёму оперативной памяти. И неважно, какого размера исходный файл.

SELECT ID_client
FROM Transactions_info
WHERE date_new BETWEEN @first_day_of_period
                   AND @last_day_of_period
GROUP BY ID_client
HAVING COUNT(DISTINCT date_new) = DATEDIFF(@last_day_of_period, @first_day_of_period) + 1