Ищю в поисковиках

Как таковой, сильной разницы нет, require будет чуть меньше ресурсов потреблять, т.к. не будет тянуться автолоадер классов. Если у вас адекватный загрузчик классов и не калькулятор, для которого каждый бит памяти важен.

Однако, использование автолоадера (composer), довольно удобно и понятнее.

Да и в пользу автолоадера, с require можно наговнокодить так, что для разбирательства: что, откуда и зачем может уйти довольно длительное время, особенно, когда куча одинаковых функций с использованием импорта пространства имён.

Телефонный номер, это набор цифр, вы можете составить такую регулярку:

"[0-9]{4,134}"

4 - минимальная длинна цифр (номера 911 и пр. вам нет смысла принимать)
134 - максимальная длинна, которая вам нужна

Эту же задачу, можно решить так:
"\d{4,134}"
"[0-9]+" от 1 символа

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

https://sqlbolt.com/ - пройдите все задания.

После, можете углубиться в справочники по mysql.

Без bash в администрировании не обойтись.

По крайней мере адекватно. Скрипты, обычно, направлены на решение конкретных задач, тогда как bash позволяет решать широкий спектр проблем минимумом усилиями: от настройки сети до анализа логов.

Да и bash удобнее, когда познакомишься с ним.

По аналогии, мороженое можно есть ногами, но использование руки и ложки - куда удобнее.

P.S. фактически bash - командная оболочка. Любую проблему можно загуглить. Также, нужно не забывать про man.

Алексей очень хорошо описал причины, которые подтверждаются некоторым личным опытом.

Очень часто, в логах сервера, в user-agent можно встретить selenium. Достаточно в конфиг прописать правило отклонения запросов с user-agent: (*selenium*) и проблема исчезает.

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

Обходить это, можно загружая страницу через браузер и случайно сдвигать мышь, случайное количество раз (от 5-10), через случайные промежутки. Спасет от ручной проверки, для большинства сайтов.

Для 100% гарантии, чтобы не банили, нужно "наводиться" на ссылки, которые нужно распарсить следующими (по очереди). Однако, в этом случае, вы пожертвуете производительностью парсера.

Как реализовать: Поднять сервис (несколько) на машине с vnc и получать страницу через браузер, имитируя работу мышкой.

Но, обычно, указать корректный user-agent достаточно. (Я, почему-то уверен, что вы остановитесь на этом варианте).

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

Владельцу сайта проще заблокировать тот ip, с которого сыпятся запросы, чем проводить оптимизацию кода сайта и выяснять, по какой причине вообще создалась нагрузка (например, из-за не проставленных индексов в бд).
А порой, это является единственным вариантом, т.к. на сервер, может прилететь за час свыше 10000 запросов к сайту с одного ip.
Для сравнения от yandex/google, за сутки, может прийти около 4000 запросов (с минимальными настройками индексации).

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

Здравствуйте.

Прочтите эту статью: https://m.habr.com/ru/post/437972/

Несколько общих рекомендаций:
1. Передавайте в cookie как, можно меньше информации, т.к. cookie имеют ограничение длинны (у большинства серверов), выход за ограничение вызовет 502 ошибку.
2. Храните как можно меньше данных в сессиях. Сессии хранятся в файлах. Единовременно, может быть только одно обращение к файлу. Чем больше храните в сессиях, тем большее информации в них записано и тем дольше будет поиск по файлу сессий, что увеличит время блокировки и скорость загрузки сайта/приложения.
Redis/Tarantol/Memcached решают проблему, т.к. позволяют хранить сессии в оперативной памяти.