Мирон

пример из книги, поищите ее, это классика

MySQL Stored Procedure Programming
By Steven Feuerstein, Guy Harrison
...............................................
Publisher: O'Reilly
Pub Date: March 2006
Print ISBN-10: 0-596-10089-2
Print ISBN-13: 978-0-59-610089-6
Pages: 636

-------------------------------------------

CREATE TRIGGER account_balance_au
 AFTER UPDATE ON account_balance FOR EACH ROW
BEGIN
  DECLARE dummy INT;

  IF NEW.balance<0 THEN
     SET NEW.balance=NULL;
  END IF;

END
$$

и что, вы взяли коэффициент к в 0 часов, ав 0 часов 1'' коэффициент k поменялся k`, и кто-то тем старым коэффициентом k воспользовался.
Вы серьезно ок забыть, какой он был?
Наверное даже во время запроса по списку, часть коэффициентов изменится, по мере считывания, при том, что все, как задумано,но по-честному Вам бы наверное хотелось список "к" в 0 часов список в 0 часов + 1 версия + 2 ... n версия.
Учитывая 300 значений/3 секунды по 32 бита на каждый получаем 1,2МБ в час. В принципе копейки для MySQL
Редиску можно встроить для текущего слепка, если хочется немедленный ответ из буфера.

Не удалось выполнить действие "Создать" для следующего объекта: "Пользователь", "sa".
---
И чем вас это обеспокоило? Пользователь sa уже создан, ошибка в данном случае вполне может быть проигнорирована.
---
Есть наверное различные пакеты для трансляции MSSQL Server -> MySQL. запрос в Яндексе "migration from sql server to my sql" третьей линией привел сюда.
По опыту, на поверхности, многое действительно поддается трансляции, но процедуры и функции, нет.
Но чуть от поверхности, MySQL уступает в плане отладки и выявления ошибок. А проблемы с правами пользователей мало отличаются. Попытка создать пользователя, который уже есть приведет к той же ошибке и в MySQL.
Есть конечно возможности отладить код создающий объекты, применяя "IF NOT EXIST" выражение. Профессионалы используют два подхода для кода создающего объекты.
Подход №1 - фирменный подход специалистов, проверять существование объекта, прежде чем его создать.
Людям свойственно это делать, чтобы обеспечить наименьшие трения с чтением и пониманием ошибок. В этом случае детальное чтение ошибок необходимо для выявления дефектов.
Такой код удобен тем, что его можно повторять снова и снова, результат будет всегда один и тот же, а ошибки будут выданы только в случае дефекта, или записи будут чистыми.
Подход №2 - обычно используют создатели по, которое пишет скрипт "создать такой-то объект", с оглядкой на профессионального пользователя, который ( как считают создатели по ) достаточно знаком и с синтаксисом, и с важностью тех или иных сообщений, и сможет прочитать "с листа" записи машины, и справиться с выдачей решения "все хорошо" или "что-то сломалось" благодаря накопленным знаниям.
У меня сложилось впечатление, что Вы работаете с кодом, созданным в подходе №2. Возможно если Вы прибавите детали, и опишете что Вы делаете, отвечающим на вопрос будет проще справиться с ответом.
Всего хорошего

Мне больше нравятся секвенции. Около часа назад, когда нашел вопрос оказалось, что мой pgAdmin 4 серьёзно поотстал. Поставил новый, уже 64-х битовый, подсоединился к настольной службе, и только через GUI построил следующие объекты, никуда не торопясь. Все удивительно приятно и удобно. Надеюсь пригодится :)

CREATE SEQUENCE public.testincrement_sequence
INCREMENT 1
START 1
MINVALUE 1
MAXVALUE 9223372036854775807
CACHE 1;

CREATE TABLE public.testincrement
(
i integer NOT NULL DEFAULT nextval('testincrement_sequence'::regclass),
a character varying(250) COLLATE pg_catalog."default",
dt timestamp without time zone,
un character varying(128) COLLATE pg_catalog."default"
)
WITH (
OIDS = FALSE
)
TABLESPACE pg_default;

снимите привилегии пользователей, которые сейчас созданы в базе данных. Оставьте им право читать. Особое внимание уделите административным учетным записям, например root. В моей практике мне не приходилось защищать конкретно MySQL, поэтому я не знаю, можно ли изменить имя пользователя root, если можно, сделайте это, конечно же изменив его пароль.
Сделайте специальный логин, которому присвоено разрешение изменять данные. Запомните пароль этого пользователя и сложите его в сейф. Ключ от сейфа повесьте на шею и никому не давайте.
Сделайте так, чтобы вход с паролем этого пользователя имел отдельный доступ к базе данных. Чтобы его не надо было выводить где - то в конфигурации программы, обеспечивающей работу сайта. Входите в этот счет с паролем через защищенное приложение так, чтобы никто не смог ни увидеть ваш пароль, ни считать его через какие - то устройства, в частности тех, которые слушают что передается по сети. В принципе все современные программы, которые приходят с продуктом защищают пароль логина. Но детали могут быть существенны, прочтите документацию, если есть сомнения. Там как правило описывается хорошо ли защищен сам процесс присоединения к базе данных тем или иным устройством.
Ну и наконец, защитите таким же подходом машину на которой установлена база данных и сайт.
В конце - концов, если с первой попытки не получится, и кто - то продолжит "безобразничать", повторите цикл, только теперь уже с некоторым опытом прежней тренировки.
По мере работы над этой областью рано или поздно Вы столкнетесь с тем, что либо человек, либо какой - то процесс установленный либо на машине, либо в самом приложении сайта, выполняет подмену указателей адресов, либо заметив этот процесс и сличив временные метки записей - их изменений, либо заметив, что кто - то присоединился к базе данных без разрешения с высоко привилегированным пользователем. Обнаружить это можно так же установив триггеры на таблицах, фиксирующие изменения, включая время записи имя учетной записи и значение поля до изменения и после. Проблема в том, что Ваша база в данный момент эксплуатируется не по назначению неким третьим лицом, и это лицо может исказить и эти трассировочные записи, поэтому на начальном этапе необходимо все - таки изолировать пользовательские записи и засекретить вход имеющий привилегии менять данные и административно распоряжаться ресурсами.

Не пробовали поискать в яндексе?
Я ввел запрос "MySQL for json" выражение "for json" поддерживается в SQL Server и это считается золотой стандарт СУБД, поэтому похожие функции в других СУБД можно искать по ключевым словам.
Вот ответ, по - моему подходит.
https://stackoverflow.com/questions/41758870/how-t...

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

Для MySQL было бы хорошо подтвердить что таблица категорий создана с поддержкой InnoDB. Если так, то проверьте если есть, и если нет, то добавьте индекс
CREATE INDEX IX_product_categories_NC1 ON product_categories ( parent_id, name, id );