Akina

Это верно или нет???

В общем случае нет. Точнее, зависит от настроек при установке/конфигурировании. ЕМНИП при использовании предопределённого профиля разработчика сервер настраивается только на использование socks/shared memory, соответственно сетевой интерфейс (даже локалхост) не слушается и внешние подключения невозможны.

Смотрите настройки. skip_networking, bind_address и т.п.

Server Option, System Variable, and Status Variabl...

столкнулся с ошибкой

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'IDENTIFIED BY '123' WITH GRANT OPTION' at line 1

Позорище... вот что мешает читать не всякую срань в интернете, а официальную документацию, причём для именно той версии ПО, которая используется?

Но таблиц стало много и неопределённо много.

Вижу два варианта.

Первый - таблицы принципиально различаются. Просто запросы к ним внешне весьма похожи. В этом случае подобное объединение логически несвязанных запросов в один на основании всего лишь текстового подобия - как минимум бессмысленное, а по большому счёту и вредное, действие.

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

Отдельно стоИт вариант, который является подвариантом первого, с той лишь особенностью, что тексты запросов абсолютно совпадают. В этом случае возможным решением может служить хранимая процедура, куда передаётся в виде параметров и имя таблицы, и значение критерия, а внутри выбирается либо строится с помощью CASE текст запроса, выполняемый потом динамическим SQL.
Поясню вариант "строится" - имя таблицы передаётся как параметр хранимой процедуры, там он сравнивается с набором предопределённых литералов, и уже этот предопределённый литерал, а не переданный параметр, участвует в построении текста запроса.

На строго в рамках PDO - полностью согласен с предыдущим оратором. Никак.

Шаблон:

UPDATE main_table
JOIN ( SELECT id, MAX(created_at) AS created_at
       FROM ( SELECT id, created_at from slave1
              UNION ALL
              SELECT id, created_at from slave2
              UNION ALL
              ...
              UNION ALL
              SELECT id, created_at from slaveN             
              ) AS alldates
       GROUP BY id
       ) AS maxdate USING (id)
SET main_table.created_at = maxdate.created_at

А к какой заднице тут вообще CRON прислонился?

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

Using the Event Scheduler

PS. И в запросе следует избавиться от WHERE IN и переписать его на обычный JOIN.

Предполагая, что тип данных поля - DECIMAL(xx, 3):

SELECT MIN(value) + 0.001
FROM test t1
WHERE NOT EXISTS (
  SELECT NULL
  FROM test t2
  WHERE t1.value = t2.value - 0.001
  );

https://dbfiddle.uk/9Yyi-pol

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

захожу через putty по SSH и гружу по
mysql -u****** -p****** ******* < *******.sql

Напрасно.
Загрузи CLI, а уж потом в нём грузи дамп командой SOURCE.
Во-первых, не будет тайм-аута, интерактивно клиент, в отличие от безынтерфейсного, не воспринимается как померший, ибо постоянно льёт в выходной поток. Во-вторых, будешь видеть диагностику загрузки (особенно если запустишь CLI с ключом --tee).

Не надо хранить бинарные файлы в БД.

В дополнение ко всему сказанному - в MySQL извлечение сохранённых бинарных файлов именно в виде файлов, а не массива байтов, тоже занятие нетривиальное. Выполняется по одному, запросом SELECT INTO DUMPFILE, да ещё и отдельно от остальных полей записи.

Есть товары, которые прилетают по API, их заношу в бд, но иногда часть товаров отсутствует в API и в бд нужно обнулить остатки.

Элементарно.

То, что приходит по API, нужно не пихать сразу в рабочую таблицу, а сохранить во временную таблицу. А потом обновить рабочую таблицу, используя полученные данные как источник данных. Потребуется два запроса - первый обновит записи о товарах, имеющихся в пришедшем списке, и добавит новые (INSERT .. SELECT .. ODKU), второй поставит требуемую пометку в нужном поле (UPDATE .. FROM .. LEFT JOIN .. WHERE .. IS NULL).

Альтернативный вариант - добавить в таблицу (если не имеется, что было бы весьма странно для описываемой системы) поле штампа времени обновления записи (updated_at). Перед обновлением по данным API зафиксировать время начала процесса (получить запросом с сервера MySQL), после чего вторым запросом поставить соотв. пометку в те записи, где этот штамп времени ранее запомненного.

Проблема миграции базы данных с mysql 8 на mariaDB 10?

Проблемы ОБЯЗАНЫ БЫТЬ. MySQL и MariaDB расфоркнулись достаточно давно, изменения и дополнения в синтаксисе они не синхронизируют, так что неудивительно, что чем дальше, тем меньше они совместимы. И соответственно всё меньше шансов. что дамп одной СУБД беспроблемно натянется на другую.

Такой перенос надо делать руками.

1. Выгружаем дамп структуры (без данных) из MySQL.
   
2. Экспортируем данные из MySQL-таблиц в CSV.
   
3. Правим дамп структуры руками, приводим к требованиям синтаксиса MariaDB.
   
4. Загружаем структуру в MariaDB, убеждаемся, что работает. Дропаем.
   
5. Делим дамп на 2 части - в одной только таблицы (и другие критично необходимые для создания таблиц объекты), в другой всё остальное (индексы, представления, триггеры-функции и прочая тряхомудия).
   
6. Грузим первую часть дампа структуры.
   
7. Импортируем данные из CSV в таблицы MariaDB.
   
8. Грузим вторую часть дампа структуры.
   

Запустите ярлык на CLI из окна CMD и смотрите сообщения. Больше всего похоже на сбой аутентификации.

в какой таблице будет храниться набор необходимых полей для вставки неизвестно

Бред сивой кобылы (извиняюсь). Структура (точные имена полей, и в какой таблице какое поле) обязана быть заранее известна. Даже если используется псевдодинамическая структура на базе EAV или иным способом организованная.

у меня есть 2 таблицы или допустим будет 3 ... Я хочу при выполнении insert into или update использовать эти таблицы

MySQL не реализует одновременную вставку в более чем одну таблицу. А также не реализует использование запроса на вставку в CTE. Напрямую задача не решается.

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

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

На версии 8+ как-то так:

WITH cte AS (
    SELECT `events`.`id`,
           `events`.`date_public`,
	   `event_categories`.`id` as `cat_id`,
	   `event_categories`.`title` as `cat_title`
	   ROW_NUMBER() OVER (PARTITION BY `event_categories`.`id` ORDER BY `events`.`date_public` ASC) rn
    FROM `events`
    INNER JOIN `event_category_joins` ON `events`.`id` = `event_category_joins`.`event_id` 
    INNER JOIN `event_categories` ON `event_categories`.`id` = `event_category_joins`.`event_category_id` 
    WHERE `events`.`date_public` >= '2024-04-05 19:00:00'
--    WHERE `events`.`date_public` >= CURRENT_DATE
    )
SELECT id, date_public, cat_id, cat_title
FROM cte
WHERE rn = 1;

type X:\sql_files_folder\*.sql | Z:\mysql_bin_folder\mysql -D database_name -u account_name -p

И молись, чтобы в файлах не было синтаксических ошибок...