d-stream

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

Вероятнее всего планировщик сообразит и построит inner join, но не исключено что у него на это не хватит интеллекта и запрос будет тупить...
Посему будет гораздо честнее писать inner join

https://dev.mysql.com/doc/refman/8.0/en/with.html
красиво, рекурсивно

По-моему MySQL умеет pivot - тогда это лучший вариант.

1. bulk insert
2. при гарантированной корректности данных - немного может поспособствовать вначале влитие данных в таблицу без индексов, а уже потом alter с установкой индексов

Что мешает дорасширить исходный запрос нужными join и получать ровно нужный список?

Первое что напрашивается - отфильтровывать явно несравнимые. Например какой смысл сравнивать трехбуквенное имя с пятнадцатисимвольным?

Ну и общий вопрос: а в каком из имен Тимур, Темур и Теймур опечатка?

Волшебное универсальное средство - case
www.mysqltutorial.org/mysql-case-function

Обобщенный универсальный вариант:

update table
set ...
from table
join ....
where ...

использовать join

select * from ( select ... union select) as t1
join t2 on t1....

Чужим данным верить нельзя (с) , поэтому придется делать свой уникализатор. Например тот самый автоинкрементный id

Ну так условие-то, если его более тщательно выразить словами, должно звучать как
"находящиеся между текущей датой и датой на 5 дней больше"

то есть как минимум два сравнения или between

p/s/ обычно удобнее оперировать чем-либо типа datediff - есть разницей в днях и там более явно видно что надо "от нуля до 5 дней"

А откуда берутся данные для update?
Если из других таблиц или регулярных данных - то все это элементарно делается в виде "однострочного" действия (update) за один раз.

Пункты самовывоза - штука переменная во времени, да еще и иногда закрывающиеся-открывающиеся... Плюс история.
Так что явно пункт самовывоза - это id на таблицу пунктов самовывоза.
Притом последняя может оказаться нетривиальной по составу:
- пункт закрывается, но поток уже заказанного для него идет - нужен флажок отображать ли его в новых формах заказа
- пункт имеет ограничения по габаритам, ассортименту, времени работы и т.п. - значит это может/должно фигурировать при заказе

Можно и по мотивам старой шутки про пропускную скорость камаза с полным кузовом компакт-дисков против оптического кабеля.
То бишь остановка старого сервера, перенос диска в новый и копирование на максимальной пропускной способности шины.