Vitsliputsli

Можно, но с умом. При невысокой нагрузке, база данных скорее всего простит вам это. При высокой относитесь к json как к обычной строке, т.е. без всяких индексов и поисков по параметру внутри json, максимум когда выборка уже сделана, можно попросить СУБД выбрать нужный атрибут. Как бы PostgreSQL не агитировал за json, поиск по его внутренностям всегда будет хуже по производительности.

выполнять сырые sql

Любая СУБД предоставляет широкое управление доступом, поэтому вполне можно этим вопользоваться. Если учебные таблицы нужно только читать, то можно держать их в одном месте, ограничив доступ только на чтение. Т.к. менять данные они будут только свои, то лочить друг друга не смогут. Также надо посмотреть лимиты для кол-во данных, которые пользователи могут залить в БД. Лимитировать кол-во создаваемых БД.
Несмотря на все, разумеется, лучше весь этот зоопарк держать на отдельной СУБД.
Можно, конечно, сделать это и через контейнеры. Но такая изоляция здесь не особо нужна, а накладные расходы будут очень велики, если у вас не 2 пользователя.

Вы выводите поле is_poisk, он это и показывает, хотите считать кол-во строк - используйте функцию для подсчета строк.

Шедулер на стороне СУБД, либо на стороне app. Но проще и лучше просто фиксировать время до которого резервирование активно и проверять его при опросе статуса.

Зависит от "повседневных" задач. Если не столкнетесь с адептами логики в базе, то написание хранимых процедур не понадобится. Обработка на стороне приложения как правило дешевле, но фильтрация данных и агрегация чаще всего осуществляется на стороне СУБД. Кроме основных операторов SQL нужно понимание транзакций (в том числе их уровней), варианты хранения данных (таблицы связей, EAV и прочее), нормализация, связи (внешние ключи используются почти всегда), индексы (не только какие бывают, но и как организовано сбалансированное дерево b-tree, как влияет селективность на выборку), план запроса, оптимизатор и сбор статистики, какие бывают локи и из-за чего, и для каких изменений нужно снимать нагрузку. Ну и сопутствующие вещи - миграции, фикстуры, драйверы СУБД, подготовленные запросы, sql-инъекции и т.п. Для начала достаточно иметь общее теоретическое понимание этих вещей, реально будете их изучать на практике, в зависимости от проектов и их нагрузки с разной степенью глубины.

Как вариант, передавать в переменную значения разделенные запятыми, в процедуре IN заменить на FIND_IN_SET, что-то вроде:
select * from test where find_in_set(field, 'var1,var2,var3')>0;

Вместо
(`task`.`executor_id` != 5)
нужно написать
(`task`.`executor_id` is null)

откуда взялось 5 совершенно непонятно.

Если версия MySQL позволяет, смотрите аналитические функции.
Если нужно на 5.7, то можно применить следующую магию:

select 
        case when @userId<>user_id then @q:=1 else @q:=@q+1 end q,
        case when @q=1 then @userId:=user_id else @userId end user_id
    from (select * users_images order by user_id) t1, (select @userId:=0, @q:=1) t2
    where user_id<>@userId or (user_id=@userId and @q<=2)

Здесь мы получаем из таблицы users_images по 3 элемента в каждой группе по user_id. Лимит установлен в самом конце <=2 - означает 3. Выглядит кошмарно, но решая такие задачи переменными mysql часто получается так.

exception у вас привязан к insert, а ошибка возникает при вызове процедуры. Т.е вы вызываете процедуру
add_product_4 (INT, TIMESTAMP, VARCHAR, VARCHAR, INT, VARCHAR)
а увас есть только процедура:
add_product_4 (INT, TIMESTAMP, VARCHAR, VARCHAR, INT, INT)
, т.е. до выполнения INSERT даже не доходит.

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

Аналогично, но в разы быстрее будет так:

SELECT 
            "ticker_symbol" AS symbol, 
	    count(case when "request_status" = :requestStatus then 1 else null end) "pendingCount",
	    sum(case when "request_status" = :requestStatus then "amount" else null end)::varchar "expected"
	FROM "requests"  
	WHERE "wallet_address" = :walletAddress 
	GROUP BY "ticker_symbol"

Если я ниего не напутал.
А если нулевые значения не нужны, то можно еще проще:

SELECT 
            "ticker_symbol" AS symbol, 
	    count(*) "pendingCount",
	    sum("amount")::varchar "expected"
	FROM "requests"  
	WHERE "wallet_address" = :walletAddress and "request_status" = :requestStatus
	GROUP BY "ticker_symbol"

Посмотрите в сторону мандатного контроля, это в первую очередь решения на основе SELinux, и основные СУБД их поддерживают.

select
 count(port) ports_count,
 count(case when abonent!='' then 1 else null end) abonents_count
from ports

Считает кол-во строк port и abonent, исключая null и пустую строку для abonent. Если null и пустая строка одно и тоже, то case не нужен.

Можно так извратится:

SELECT * 
FROM table 
WHERE (id, make_name) IN (('1995','TOYOTA'),('5015','FIAT'),('1010','BMW'))
ORDER BY CASE 
    WHEN id='1995' THEN 1
    WHEN id='5015' THEN 2
    WHEN id='1010' THEN 3
    END

Либо делать предварительную выборку и джойнить.

Примерно так:

SELECT 
    t1.UserID,
    t1.Date DateStart,
    min(CASE 
        WHEN t2.Event='end' AND t2.Date>t1.Date THEN t2.Date 
        ELSE null END) DateEnd
FROM table t1
CROSS JOIN table t2 
WHERE t1.Event='start' 
GROUP BY UserID

хотя, возможно лучше это сделать аналитикой.
Дальше сами. С EventID у вас чтото напутано, поэтому я взял для примера простой понятный вариант. Date переделайте в timestamp: либо в запросе, либо лучше это сделать в БД, чтобы исключить подобные проблемы в будущем.

Если EventId идентификтор одного интервала времени, т.е. в таблице хранится до 2 EventId (начало и конец, или только начало, или ничего), то:

SELECT 
    t1.UserID,
    t1.Date DateStart,
    CASE 
        WHEN t2.Date is null THEN t1.Date 
        ELSE t2.Date END DateEnd
FROM table t1
LEFT JOIN table t2 ON t1.EventID=t2.EventID AND t1.Date<t2.Date

как-то так. С case выглядит не очень, но так лучше чем cross join с distinct. Ну и вместо date берите timestamp.

Что значит "достаньте работников со второго по шестого "? В нормальной работе такое не делают через LIMIT, потому как он нам даст невесть кого, а нам скорее всего нужны конкретные работники, предположу что со 2го по 6го по id, тогда:

SELECT 
        * 
    FROM workers 
    WHERE id>=2 AND id<=6
    ORDER BY age