Ипатьев

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

Заменяйте пробел на плюс
Причем лучше это делать не косолапыми ручками, а через urlencode() каждого отдельного параметра

Открыть в редакторе главную страницу, поставить курсор после слова footer, дописать -home и сохранить страницу?

Собираем логи Symfony в Elasticsearch с помощью Filebeat и Monolog

Если данные нужны для нескольких заказов, то вариант @Rsa97
Если только одного заказа, то проще двумя запросами, результат второго просто подцепить в виде отдельного элемента к массиву, полученному из первого

Большие объемы данных хранят точно так же, как и маленькие.
Любые отступления от этого правила должны быть продиктованы очень серьезными причинами. поскольку никаких причин вы не привели, то и ответ будет стандартный:
Делаете таблицу вида
route_id, lng,lat,speed,date
и пишете в нее свои точки, используя множественный insert
ошибка mysql лечится увеличением max_allowed_packet

Если речь о том, чтобы проверять по базе не по одному файлу, а собирать пачками по сто (лучше по тысяче), то задача имеет смысл.
Прерывать тупо по счетчику: накопилась тыща - провалились в if, внутри которого всю пачку по базе пробили одним запросом, лишние удалили, массив обнулили, дальше пошли.

Ну или по каталогам бить. В каждом каталоге сначала читать только каталоги и проваливаться в них, а потом считать все файлы, обработать их, и вынырнуть на уровень выше.

Тут надо не скобочьки расставлять, а весь это адов говнокод удалять. И оставить только
$remote_addr = getenv('REMOTE_ADDR');

Для не слишком принципиальных товарищей есть элементарное решение

update tasks set uuid = ? where done=0 limit 1;
// обрабатываем
update tasks set done=1 where  uuid = ?;

А принципиальные должны страдать :)

Ну и просто для комплекта, решение с использованием функций для работы с массивами

$permission = array_values(array_intersect($a, array_column($b, 'permission')))[0] ?? null;

array_column() сделает из $b нормальный массив, без этих бессмысленных "permission"
array_intersect собственно вернет пересечение двух массивов, все значения из $a, которые есть в $b.
теперь нам нужно самое первое значение из этого массива. Один из вариантов - это array_values()[0]
если нет совпадений, то при обращении к нулевому элементу будет ошибка, для её подавления используем сокращенный оператор проверки на существование, и присваиваем значение null

Если у вас задача потребляет CPU по максимуму, то да - распараллеливать её на большее количество процессов, чем имеется в наличии потоков - бессмысленно.
Но обычно задача по добавлению записи в БД потребляет не слишком много поцессора. А если речь про "парсинг", где процессор 99% времени ждет пакет из сети, распараллеливать можно хоть на десятки процессов.
Конкретное количество зависит от потребления процессора конкретной задачей.

Количество потоков не всегда равно количеству ядер, умноженному на два. Надо смотреть на конкретный процессор. Тем более на VPS, где процессор тоже виртуальный.

Если говорить про конкретный пример, то в идеале конечно надо написать нормальный код, который запишет в БД несчастные 3 тыщи товаров меньше чем за секунду. А заниматься параллелизмом уже когда счет пойдет на сотни тысяч. Тем более что цифра скорее всего взята с потолка. Я много повидал говнокода на своем веку, но такой, чтобы добавление одного товара занимало 30 секунд я даже вообразить себе не могу.

Единственная загадка - при чем тут "web", если речь идет про CLI. И, если уж говорить про веб, то с какой радости он "однопоточный".