Vitsliputsli

выполнять сырые sql

Любая СУБД предоставляет широкое управление доступом, поэтому вполне можно этим вопользоваться. Если учебные таблицы нужно только читать, то можно держать их в одном месте, ограничив доступ только на чтение. Т.к. менять данные они будут только свои, то лочить друг друга не смогут. Также надо посмотреть лимиты для кол-во данных, которые пользователи могут залить в БД. Лимитировать кол-во создаваемых БД.
Несмотря на все, разумеется, лучше весь этот зоопарк держать на отдельной СУБД.
Можно, конечно, сделать это и через контейнеры. Но такая изоляция здесь не особо нужна, а накладные расходы будут очень велики, если у вас не 2 пользователя.

Так как соединение долго не использовалось, MySQL тупо его оборвал.
Используйте для бота systemd unit с перезапуском при ошибке, ошибки бывают разные, пускай перезапускается автоматически. Хоть это и решит проблему, лучше все-таки разрывать соединение, если оно долго не используется. Или, на худой конец восстанавливать его при обрыве.

Вполне могут попросить показать код, поэтому неплохо что-нибудь держать в github на такой случай. Интересоваться будут как вы пишите, а не как оно работает. В зависимости от языка, вашего уровня и адекватности проверяющего будут обращать внимание на разные вещи.
"развитый GitHub" это когда там лежит что-то, что используют другие люди и чем большее кол-во, тем лучше. Или пулреки в крупные проекты. Если там будет гора бесполезного мусора, то это никому не интересно.

По требованиям описанным в задаче:


По требованиям, с учетом комментария "Пользователь может как откликнуться на заказ, так и выбрать исполнителя, не создавая свой заказ".

Ситуация мягко говоря странная, поэтому странные вопросы: проверьте, что у вас действительно заключен договор - есть ли у вас договор подписанный простой или электронной подписью? Понимаю, что там чтото на Госуслугах пишется, но все же. Договор трудовой или ГПХ? В порядке бреда: не может ли быть так, что на вас оформлена новая карта и зарплата идет туда. И, по новым законам, есть еще и волонтерство, с договором по котором работник несет такие же обязанности, что и по трудовому, но ему можно еще и не платить.
В принципе, за нарушение дисциплины труда, вас могут уволить, если захотят, но видно не хотят. Но при этом, понятное дело, зарплату платить обязаны. За невовремя выплаченную зарплату компания попадает на штрафы. Также запрещается работа из-за пределов территории России. И очень большие штрафы, если работник числится в компании, но не является налоговым резидентом России.
Это очень странная контора будет, если ей и на штрафы тоже плевать.

$s="fja fjd jkfd
fjdk fjdktest: fjkd jk
1 1 2"
echo "${s%test:*}"
echo "${s#*test:}"

Про форматирование, конечно, верно пишут, но если про него забыть (очень оно не стандартное, но я бы не сказал, что прям какое-то нечитабельное), то просто беглым взглядом:
1) Нет ООП (а это сейчас обязательный стандарт), попытка выдать за ООП набор статических классов делает только хуже, пишите уж лучше честно процедурно.
2) SQL-инъекции! Да и весь блок работы с СУБД чтото ужасное. Куча бесполезного, реконнекты при каждом запросе...
3) ТТУК, если конечно вообще подразумевался mvc, и контроллер это index.php.
4) Вместо автолоадера просто подключение всего и вся. Хотя по факту в php сейчас стандарт - composer.

Обычно в /etc/default/grub написано на чистом английском:
If you change this file, run 'update-grub' afterwards to update /boot/grub/grub.cfg.

Вероятно так и следует сделать.

Зачем?
Так как вы хотите не делается с точки зрения безопасности.А автоматизация производится через настройки sudoers.

Вы выводите поле is_poisk, он это и показывает, хотите считать кол-во строк - используйте функцию для подсчета строк.

Если весь массив умещается в память это уже хорошо. Как оптимизировать:
1) Создайте массивы не ассоциативные, а с обычными числовыми ключами. Лучше так и хранить, будет отдельно массив url и массив cnt, связь по числовому ключу.
2) Храните отсортированный массив, и используйте по нему, например, бинарный поиск.
3) Дополнительно можно использовать массив фиксированной длины из SPL, а не стандартный на хеш-таблицах, на таких объемах от него будет толк.

Подскажите на каком языке лучше всего Websocket? чтобы он был менее затратны в производительности и более всего понятен для изучения? :)

Go.

прочитал, что могут быть разные утечки памяти, если на php делать

Не будет, если сами их не создадите.

У вас включен файловый кеш (в том числе для cli), но отключена проверка валидности кеша (validate_timestamps). Поэтому пока вы вручную не сбросите кеш, он будет продолжать работать.
Что касается sudo, при первом запуске скрипта, вы сделали это через sudo, был создан файл кеша от root, с правами запрещающими чтение другими пользователями. При запуске без sudo php не может его прочитать и записать (хрен его знает, почему он не кидает ошибку), в итоге sudo php работает с файловым кешем, а php от пользователя нет.

Не нужно ничего сокращать. Код вполне краток и понятен. Дальнейшие сокращения лишь ухудшат читаемость.
Но если хочется поговнокодить можно взять empty.

Они не будут сортироваться, т.е. будут взяты, как прочитаны. Порядок при чтении зависит от движка, если говорить про InnoDB, то в нем данные сортированы по первичному ключу. Этот порядок зависит лишь от внутренних механизмов движка и не гарантируется, расчитывать на него и использовать в ПО нельзя.

Время выполнения - 10-12 сек в первый раз и 3-4 сек при повторных запросах

В первй раз идет "прогрев" кеша диска, поэтому долго. Повторный запрос в 3-4 секунды наверное вполне нормальный, т.к. скорее всего необходимо обработать большое кол-во данных (но, конечно, нужно смотреть план, чтобы понимать сколько он обработал).
Решение стандартное - стройте проекции. Агрегирующие с группировкой по дням, для группировок по дням, неделям, месяцам. И top-проекции для "получить 100 элементов, у которых самая большая сумма". Но нужно посмотреть как это делать, так как я больше работал с другой колоночной СУБД.