Adamos

UPDATE TableA LEFT JOIN (
SELECT MIN(Id) AS id, Name FROM TableB GROUP BY Name
) AS b
ON TableA.Name = b.Name
SET TableA.TableBId = b.id

Соотвественно, до этого запроса - ALTER TABLE с добавлением столбца TableBId, после - ALTER TABLE с удалением Name.
Можно сделать "ногой в дверь", записывая значение прямо в Name и потом ALTER TABLE его с переименованием и сменой типа, но я бы не рисковал ;)

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

Чтобы быстро сравнить структуры БД - достаточно сделать с обеих дампы без данных и открыть их в Meld, например, для визуального сравнения.

Раз все равно "все, которые остались", значит, это вопрос условия сортировки.
Условие пока не сформулировано - если статус 1 у пяти статей, которые три из них надо брать?
Ну, и вымучивая один запрос, неплохо бы проверить, не получится ли он медленнее четырех простых: взять три последних айдишника (индекс, мгновенно), один первый (аналогично), три первых (видимо) по статусу, исключая полученное на предыдущих запросах (а вот с этим в одном запросе подзатрахаешься конкретно) - и окончательный селект, у которого в сортировке указаны эти айдишники как повышающие приоритет.

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

P.S. Подозреваю, третье условие просто сформулировано через жопу, и отдельного запроса здесь не надо - просто сначала вывести со статусом 1, а потом без.

Самописные "защиты от инъекций" вследствие непонимания автором того, что он вообще делает, обычно убивают двух зайцев сразу.
И оставляют дыру в безопасности, и портят данные в базе.
Для реальной защиты подготовленного запроса, как правило, достаточно. Но если очень постараться, дырку можно проделать и в нем.

Берешь блокнот, умеющий регулярки, превращаешь (\w+) (\d+) в ('$1', $2),.
Добавляешь первой строчкой команду INSERT - и загоняешь этот запрос в базу через то, через что с ней в принципе общаешься.

Вообще-то сервис прямо запрещает дублировать вопросы.
Тем более, что это бессмысленно.
А у этого вопроса - вдвойне.
Никто тебе через астрал не скажет, какая конкретно у тебя в БД кодировка.
А РНР тут вообще ни при чем.

В кодировке ASCII (American standard code for information interchange) нет и никогда не было кириллицы. У вас, скорее всего, cp1251.

SELECT * 
FROM products p 
WHERE p.active='1' 
ORDER BY p.id DESC
LIMIT 0,25

SELECT op.order_id, 
COUNT(op.id) AS ordersCount, 
SUM(op.count) AS countOrdersCount, 
SUM(op.price * op.count) AS ordersSum
FROM orders_products op 
LEFT Join orders o
ON op.order_id = o.id
WHERE 
op.order_id IN (/* всего лишь 25 значений из предыдущего запроса */) AND
op.item_id = p.id AND 
o.date > "2020-01-01" AND
o.status != 2

Понятно что нужна ещё и практика

Нет. Нужна еще и теория. Но никаких глубоких экспертов от зазубривания теории вы не получите.
А ответ ждет вас на форуме авиамоделистов:

- Сколько нужно времени, чтобы научиться управлять самолетом так, чтобы он не разбивался при посадке?
- Пять-шесть.
- Чего? Дней? Недель? Месяцев?
- Самолетов...

Чайникам можно начинать с методички и практикума на sql-ex.ru, и уже получив общее представление о том, что к чему - браться за основательное изучение по учебнику.