Akina

CREATE FUNCTION не входит в список конструкций, разрешённых к использованию в stored objects (procedures, functions, triggers, event procedures) и prepared statements.

Ответ: НЕЛЬЗЯ.

PS. В MySQL нет временных функций, все функции - статические. Встроенные, регистрируемые либо хранимые.

No index used in query/prepared statement ...

что это означает?

Это означает, что, по мнению PHP/mysqli, нет подходящего индекса для обработки запроса, сервер будет шерстить всю таблицу, что неэффективно. В общем, он просто старается сделать тебя счастливым (твоё мнение при этом никого не интересует).
Возможные решения:
1. Создать индекс users (username)
2. Изменить настройки mysqli_report() (см. ответ SagePtr)

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

Тогда альтернатив вообще нет.

Создать уникальный индекс users (username).

После этого код с проверкой на существование можно смело выбросить (дубликат в принципе не будет записываться сервером). Но обязательно добавить код для обработки ошибки дублирования при добавлении.

Нет такого понятия как местные переменные.

Есть переменные локальные. Они определяются в рамках блока кода в хранимой конструкции (функция, процедура, триггер и пр.), имеют определённый тип, и существуют только в том блоке, в котором определены. Имя начинается НЕ с символа @.

Есть переменные, определённые пользователем. Имя начинается с символа @. Не требуют определения, существуют в течение всей сессии.

В показанном коде - мешанина. Попытка определить пользовательскую переменную, что приводит к ошибке синтаксиса. Показанный код был бы корректен в MS SQL (SQL Server), но не в MySQL.

В общем, собак - убрать. Всех.

SELECT COALESCE( 
    (
        SELECT busy FROM `all_reservs` WHERE dates ='27.06.22' AND number='22' LIMIT 1
    ), 
    'no'
) AS busy;

Если запрос вернёт запись (с одним полем), скаляризация преобразует её в значение, и COALESCE вернёт это значение.
Если запрос не вернёт запись, скаляризация вернёт NULL, и COALESCE вернёт 'no'.
LIMIT страхует от возврата более чем одной записи. По-хорошему ещё надо добавить ORDER BY.

SELECT t1.*
FROM table AS t1
NATURAL JOIN (
    SELECT user_id, MAX(timestamp) AS timestamp
    FROM table AS t2
    GROUP BY 1
) AS t3

Если вдруг для юзера время может иметь дубликаты - будут выведены все соотв. записи.

SELECT ..
FROM ..
GROUP BY (unixtime_column MOD 60*60*24) DIV 60*60

Если просто переписать в соответствии с правильным синтаксисом, и при этом избавиться от ненужного IF, то

CREATE DEFINER=`sql_test`@`%` EVENT `Маркировка` 
ON SCHEDULE 
    EVERY 1 HOUR 
    STARTS '2022-05-29 23:15:23' 
-- ON COMPLETION NOT PRESERVE   -- не имеет смысла для периодической задачи
-- ENABLE                       -- по умолчанию эвент включен при создании
DO
UPDATE `tasks` 
SET `status` = 4  
WHERE `status` = 3
  AND EXISTS ( SELECT NULL  
               FROM `config` 
               WHERE `name` = 'profile_deleting'
                 AND `value` = 'allowed' );

Однако логика какая-то странная - обновляются все записи, и при этом проверяется наличие абы какой записи. Хотя разум требует наличия зависимости между обновляемой и проверяемой записями.

======

Впрочем, никто не запрещает сохранить исходный вид:

CREATE DEFINER=`sql_test`@`%` EVENT `Маркировка` 
ON SCHEDULE 
    EVERY 1 HOUR 
    STARTS '2022-05-29 23:15:23' 
-- ON COMPLETION NOT PRESERVE 
-- ENABLE 
DO
BEGIN
  IF (SELECT `value` FROM `config` WHERE `name` = 'profile_deleting') = 'allowed' THEN 
    UPDATE `tasks` SET `status` = 4  WHERE `status` = 3;
  END IF;
END;

Но:

1. при создании такой процедуры придётся переопределять DELIMITER
   
2. если подзапрос вернёт более одной записи - это приведёт к ошибке
   

Проблему с возвращающим более одной записи подзапросом можно поправить следующим изменением:

IF 'allowed' IN (SELECT `value` FROM `config` WHERE `name` = 'profile_deleting') THEN

WebDiez

Затупил.. Нашел вариант..

Пока надо обновлять для строго одной записи - сойдёт. А вообще

UPDATE request 
JOIN ( SELECT MAX(id) id 
       FROM request 
       WHERE user_id IN ( '97'  /* список */ )
     ) subquery USING ( id )
SET request.message = 'text';

WITH `cte` AS (
    SELECT 123 `id`, 1 `stat` UNION ALL
    SELECT 321     , 2        UNION ALL
 -- ...
    SELECT 456     , 8        UNION ALL
    SELECT 789     , 9
)
UPDATE `data`
JOIN   `cte` USING ( `id` )
SET `data`.`stat` = `cte`.`stat`;

ALTER TABLE customer
ADD CONSTRAINT CHECK(phone REGEXP '^[0-9]{3}-[0-9]{2}-[0-9]{3}$');

https://dbfiddle.uk/?rdbms=mysql_8.0&fiddle=71012d...

В общем случае - нет.

Как я понимаю, мысль твоя бредёт вот в каком направлении: мы выполняем INSERT в основную таблицу, а триггер AFTER INSERT, имеющий доступ к сгенерированному значению автоинкрементного ключа именно свежесозданной записи, создаёт записи в связанных таблицах, используя именно это значение.

Так вот именно эта мысль - она некорректная. Причём по совершенно элементарной причине. Данные для вставки в связанных таблицах (не поля связи - других полей) триггер тоже должен откуда-то взять. А вот корректно передать их достаточно непросто. Их нельзя вставить в блок данных основной записи - там просто места для этого нет, сервер перед выполнением INSERT проверяет входные данные на соответствие количества значений количеству переданных данных, соответствие типов, непревышение размеров и пр. Значит, данные придётся передавать за пределами запроса. Да, тут есть варианты, типа определённых пользователем переменных, временных таблиц и протчая - но всё это ненадёжно, сложно и совершенно несопровождаемо. Следует ещё учесть то, что триггеры - это конструкция неотключаемая. Либо она выполняется при абсолютно любом INSERT, и тогда есть определённые проблемы (триггер, предназначенный для работы при INSERT .. VALUES с единственным блоком данных, вряд ли корректно обработает вставку нескольких блоков данных, INSERT .. SELECT или LOAD DATA), либо для выполнения запросов на массовое добавление триггер надо удалять и потом пересоздавать - а если это происходит в конкурентной среде?

В общем, триггер - неподходящая идея. Вот хранимая процедура (stored procedure) - это самое оно. Там можно реализовать логику ну практически любой сложности, с любыми обработками и проверками. Хотя и не следует забывать, что триггер выполняется наново для каждой отдельной вставляемой записи, так что его наличие, даже при достаточно простом и компактном коде, сильно скажется на скорости выполнения операций вставки, особенно вставки массовой.

при регистрации пользователя, я получаю lastInserdId() и добавляю статичные данные для этого пользователя в различные таблицы

Ненадёжно. Если между вставкой в основную таблицу и получением LAST_INSERT_ID() соединение будет разорвано и затем автоматически восстановлено, то полученное значение будет некорректным (вернее, получите NULL). А свежесозданная запись благополучно "повиснет в воздухе".
Чисто теоретически, базовая таблица пользователей обязана обеспечивать уникальность записи даже без учёта синтетического первичного ключа (например, поле логина явно должно быть уникальным). А коли так, и с учётом того, что все значения для свежевставленной записи нам известны, можно использовать INSERT INTO slave SELECT 'literal', main.id FROM main WHERE uniquecolumn = 'new value'.

PS. Не знаю, почему при обучении вставке данных все начинают с INSERT .. VALUES - как по мне, глубоко порочная практика. Сначала надо изучить и досконально освоить INSERT .. SELECT, и только потом упоминать про INSERT .. VALUES как более простой конструкции, применимой в частных случаях.

Если отформатировать запрос, то он выглядит так:

SELECT * FROM `rsi` WHERE `tf`='4h'                         UNION 
SELECT * FROM `rsi` WHERE `tf`='15m'                        UNION 
SELECT * FROM `rsi` WHERE `tf`='4h'                         UNION 
SELECT * FROM `rsi` WHERE `situation`='perek' AND `tf`='1d' UNION 
SELECT * FROM `rsi`                                         UNION 

SELECT * FROM `levels` WHERE `situation`='support' AND `tf`='4h' UNION 
SELECT * FROM `levels` WHERE `tf`='1h' 

ORDER BY `time` DESC LIMIT 0,20

Сразу видно, что первые 4 подзапроса можно смело удалить.
А потом надо смотреть на структуру таблицы rsi, ибо именно из неё будут взяты имена полей объединённого набора записей. Судя по ошибке, там просто нет поля time.