Akina

CREATE TABLE trs (
    wallet_id INT, 
    amount DECIMAL(12, 2), 
    hash BYTEA GENERATED ALWAYS AS (sha256((wallet_id + amount) :: TEXT :: BYTEA)) STORED
)

из конкатенированный строки wallet_id + hash

Вообще-то оба поля чисельные - какая в пень конкатенация-то? Но если их надо преобразовать в строку и конкатенировать, то

CREATE TABLE trs (
    wallet_id INT, 
    amount DECIMAL(12, 2), 
    hash BYTEA GENERATED ALWAYS AS (sha256((wallet_id :: TEXT || amount :: TEXT) :: BYTEA)) STORED
)

Использовать надо INSERT .. SELECT

WITH cte_id  AS (
    INSERT INTO words (name_word, discription_word) 
    VALUES ('cool', 'круто') 
    RETURNING Id
)
INSERT INTO users_words (users_id, words_id, status_learn_word)
SELECT 649651821, id , 0
FROM cte_id;

Если просто переписать в соответствии с правильным синтаксисом, и при этом избавиться от ненужного 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...

Вы сравниваете тёплое с мягким.

Firewall - это программа или комплекс программ, выполняющая фильтрацию на основе правил. В т.ч. на основе ACL.
ACL - это правило либо блок данных для правила. В т.ч. это может быть и правило для Firewall.

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

Как я понимаю, мысль твоя бредёт вот в каком направлении: мы выполняем 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 как более простой конструкции, применимой в частных случаях.

Допустим, существует некий алгоритм, который преобразует последовательность X длины M в последовательность Y, причём существует обратное преобразование. Неважно, что это за алгоритм конкретно - сжатие, создание "зерна" и пр. Но очевидно, что:

1. Количество вариантов последовательности X составляет K в степени M, где K - размер словаря, т.е. количество возможных различимых значений одного элемента последовательности X. В случае байтовой последовательности это байт, т.е. K=256.

2. Каждая последовательность X после преобразования даёт последовательность Y, причём две разные последовательности X дают разные последовательности Y.

Соответственно количество возможных последовательностей Y равно количеству возможных последовательностей X. И соответственно если существует хотя бы одна последовательность Y короче последовательности X, то существует хотя бы одна последовательность Y длиннее последовательности X.

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

Что же до "зерна", которое разворачивается в гигабайты - во-первых, количество финальных миров определяется количеством значений "зерна", то есть вовсе даже не такое бесконечно большое, как кажется, во-вторых, созданный образ мира содержит значительное число повторяющихся элементов, а создание копий - это немножко не декомпрессия.

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

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.

Если текущая версия СУБД поддерживает оконные функции - то ROW_NUMBER() в CTE и отбор по rn=1 во внешнем запросе.

WITH cte AS (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY list_name ORDER BY date DESC) rn
    FROM table
    )
SELECT *
FROM cte
WHERE rn = 1

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

SELECT t1.*
FROM table t1
NATURAL JOIN (
    SELECT list_name, MAX(date) date
    FROM table
    GROUP BY 1
    )

Оба запроса предполагают уникальность (list_name, date).