Сергей Ерин

SELECT "id", "price_fallback" AS "price", "price_base" AS "price_old"
FROM (
  SELECT 
    "c"."product_id" AS "id",
    "c"."price_fallback",
    "c"."price_base",
    ROW_NUMBER() OVER(PARTITION BY "c"."product_id" ORDER BY "c"."price_fallback") AS rn
  FROM "product" "p" 
  INNER JOIN "cache" "c" ON p.id = c.product_id 
  INNER JOIN "vendor" ON p.vendor_id = vendor.id 
  WHERE ("c"."showcase_id" IN (66, 1))
)
WHERE rn = 1
ORDER BY "id"
LIMIT 50;

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

Имхо, сделать две модели: Companies.php и Users.php.

$search = Users::find()->with('Companies')->where([условие])->all();

Дальше разбирать полученный массив.
Рекомендую использовать ArrayHelper

Ничего страшного, допишите еще один case и метод, и все будет нормально. Да, это нарушает принцип, но все так делают, просто хрен кто признается. Не пытайтесь здесь вкрячить какого-нибудь монстра, сложный код - это потенциальные ошибки, если возможно написать просто, так и нужно сделать.
Принципы - они принципы, а не законы, надо следовать не букве, а смыслу. Принцип открытости и закрытости оберегает нас от ошибок и дополнительных затрат на тестирование кода, который вроде бы и так уже работает и хорошо себя зарекомендовал. Т.е. если бы у вас был один метод и вы там внутри как-то хитро разруливали работу с разными типами и при добавлении нового типа изменяли бы его - это было бы ужасно. В текущей реализации, вам нужно будет добавить новый метод (это не изменит поведение класса до вмешательства), и добавить новый путь при использовании нового типа - да, вмешательство, но оно минимально. Если умудритесь накосячить здесь, то вас уже никакие принципы не спасут.
Если же у нас, что-то гораздо более сложное, либо класс физически недоступен для изменений, или он уже вовсю используется, а новый тип нужен только для конкретной реализации, то, пожалуйста, есть наследование. Наследуете класс, в потомке добавляете метод и заменяете метод, выполняющий перенаправление (не забывайте, что есть вызов parent). Это будет полностью соответствовать принципу.
Но я бы больше уделил внимание тому, почему мы ориентируемся для выбора метода на внутреннее свойство, точно ли это должны быть методы, а не отдельные классы. И вполне может быть получится так, что все эти танцы с бубнами не нужны.

Кусок кода: Question::find(), генерирует ActiveQuery, отнаследуйтесь от стандартного, и реализуйте часто используемые конструкции в нем.

Документация: https://www.yiiframework.com/doc/guide/2.0/ru/db-a...

Индексируй таблицы. Запрос у тебя простой. Не вижу что тут можно оптимизировать

Попробуй WHERE NOT EXISTS

SELECT `question`.* 
FROM `question`
WHERE 
	`question`.`deleted` = 0 AND
	`question`.`moderated` = 0 AND 
	`question`.`published_date` > 0 AND
	NOT EXISTS (SELECT `id` FROM `comment` WHERE `question`.`id` = `comment`.`material_id`) 
ORDER BY `question`.`published_date` DESC 
LIMIT 15;

MariaDB fiddle

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

if ($arg_lang) { return 301 /$arg_lang$uri; }