Rsa97

не понятно, какой влияние оказывает третья таблица на вторую

Напрямую никакого. У вас INNER JOIN `wp_company_rates` и `wp_term_relationships`, поэтому естественно, что в финальную выборку попадут только те строки, которые совмещаются по условию JOIN'a. Если после RIGHT JOIN вы получили в объединённой строке `wp_company_rates`.`post_id` равное NULL, то, естественно, в INNER JOIN эта строка не войдёт.

Всё очень просто. Приоритет операций.
x OR y OR z AND q будет выполняться как x OR y OR (z AND q), так как приоритет у AND выше, чем у OR.

SELECT `time`, `ticker`, `price`, `volume`,
       `icon`, `tf`, `figure`, `figure_text`
  FROM `figure`
  WHERE `figure` IN ('vklin', 'nklin', 'doublev', 'doubled', 'mflag', 'bflag', 'flag')
    AND `tf` IN ('1h', '4h', '1d')
UNION SELECT `time`, `ticker`, `price`, `volume`,
       `icon`, `tf`, `situation`, `situation_text`
  FROM `levels`
  WHERE `situation` = 'resistance'
    AND `tf` IN ('1h', '4h', '1d')

EXPLAIN вам в руки. Универсального алгоритма нет, СУБД сама решает, когда и какие индексы использовать. ЕМНИП, MySQL использует для этого селективность выборки и накопленную статистику использования таблицы.
https://dev.mysql.com/doc/refman/8.0/en/optimizati...

А почему PostgreSQL не должен ругаться на диалект DB2? Разные СУБД, разные диалекты. Не всё, что возможно в одной СУБД, напрямую переносится в другую.
Хотите, чтобы запросы работали везде более-менее одинаково - используйте подмножество ANSI (SQL-89 или SQL-92). Хотите переносить нативные запросы из одной СУБД в другую - изучайте обе и ищите аналоги команд/функций/опций.

А какой диалект SQL?
Для MySQL нужна кодировка колонки utf8mb4.

Полностью уберите условие присоединения. Тогда строка из Max_amount будет присоединена к каждой строке из book.

and t1.номер_детали != t2.номер_детали AND t2.номер_детали != t1.номер_детали

заменить на
and t1.номер_детали < t2.номер_детали

SELECT *
  FROM users AS u
  LEFT JOIN user_role AS ur ON ur.user_id = u.id
  LEFT JOIN roles AS r ON r.id = ur.roles_id
  WHERE u.login = :login

Слишком низкая селективность индекса. Оптимизатор решил, что полное сканирование таблицы выгоднее, чем использование индекса.

Для PostgreSQL триггер не нужен. Делается через генерируемое поле как-то так:

CREATE TABLE "table" (
  field1 VARCHAR(16),
  field2 INT GENERATED ALWAYS AS (
    ARRAY_POSITION(ARRAY['value1', 'value2', 'value3', 'value4'], field1::TEXT)
  ) STORED
);

Или, если значения идут не по порядку, то

CREATE TABLE "table" (
  field1 VARCHAR(16),
  field2 INT GENERATED ALWAYS AS (
    (ARRAY[0, 11, 22, 44])[ARRAY_POSITION(ARRAY['value1', 'value2', 'value3', 'value4'], field1::TEXT)]
  ) STORED
);

В самом запущенном случае можно так:

CREATE TABLE "table" (
  field1 VARCHAR(16),
  field2 INT GENERATED ALWAYS AS (
    CASE field1
      WHEN 'value1' THEN 0
      WHEN 'value2' THEN 11
      WHEN 'value3' THEN 22
      ELSE 44
    END
  ) STORED
);

LEFT JOIN

Это у вас просто что-то с отображением на экране. Там вообще нет ни одной жирной линии.