Чудес не бывает. Запрос - детерминированный. А потому есть лишь одно предположение - MySQL от кода при запуске на сайте получает не такой текст запроса, какой ты видишь в дампе.
Посему рекомендую - включить временно General Log, выполнить код на сайте, и посмотреть, какие запросы были получены сервером от кода.
Бизнес-процессы в магазине могут быть организованы по-разному. Соответственно и схемы могут быть разные.
Выкладывайте описание бизнес-процесса и выполненный анализ предметной области - будем смотреть, соответствует одно другому и составленной схеме или нет.
Навскидку могу сразу сказать, что схема косая. Денормализована таблица адреса. Лишняя связь между товаром в магазине и товаром в заказе (Вы путаете pattern и entity). Хранение цены во FLOAT, а даты и времени в отдельных полях - тоже ошибка. Это то, что видно сразу.
lag() и lead() берут только по одной строке, а разрыв между активностями может быть больше
Вообще-то запрос должен включать опорную таблицу календаря, содержащего все даты периода (используем генератор или рекурсивный CTE). А создание добавляемых записей лучше выполнять не с помощью оконных функций, а латеральным джойном имеющихся данных к календарю.
Какой смысл делать SELECT *, если проверяется только существование записи? Гораздо разумнее выбирать какой-нибудь литерал, скажем, SELECT 1 или даже SELECT NULL.
Оно, конечно, "Чтобы правильно задать вопрос, надо знать бОльшую часть ответа". Но для того, чтобы грамотно задать вопрос, этого не требуется - достаточно наличия базовых знаний и владения терминологией. Кстати, это же необходимо, чтобы понять ответ.
Посему рекомендую - включить временно General Log, выполнить код на сайте, и посмотреть, какие запросы были получены сервером от кода.