Adamos

Если это именно честный бот, работающий через Bot API, то он не может первым начать разговор с человеком, ему ни ID ни username не нужны.
Если он имитирует обычного пользователя, то его с большой вероятностью вскорости забанят.

pgadmin не дает исправить.

Значит, используйте SQL-запрос. И повнимательнее - чтобы количество ошибок при выполнении запроса не увеличилось...

таблица не имеет primary key

Создайте в таблице первичный ключ. Лучше синтетический.
С другой стороны, вы пишете:

отредактировать строки, связанные с этим пользователем

Если есть связанные записи - значит, есть внешние ключи и соответственно как минимум уникальные индексы. Что-то как-то не бьётся...

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

Создайте соответствующие ограничения (UNIQUE index) в структуре.

Мне бы не хотелось менять структуру таблицы

А регулярно купаться в дерьме - хотелось бы? Хотите спокойно спать - отставьте свои хотелки в сторону и сделайте так, чтобы проблем, подобных описанной, не могло произойти в принципе.

А всё намного проще. "дроны" это просто повод, как "деградация серверов" у ютуба...

В отладку входит два основных механизма:
1. Включение полного отображения ошибок (или логирования, если на боевом сервере)
2. Пошаговая трассировка с контролем состояния переменных (с использованием IDE или вручную через var_dump/die).

В вашем случае, очевидно что не был выполнен пункт №1. Какой бы ни была причина проблем, РНР всегда выдаст ошибку. Так что в вашем случае надо было просто убедиться, что error_reporting=E_ALL, а display_errpos=1

А вот нижеследующее утверждение не имеет смысла

PHP данную ошибку не показывал, т.к. не использовалась функция проверки записи в директорию is_writable().

РНР не нужны никакие функции, чтобы сообщить об ошибке. А is_writable() обычно используется как раз наоборот, чтобы подавить ошибку и дальше работать как ни в чём не бывало. Ну или в лучшем случае выбросить какую-нибудь бессмысленную ошибку типа "Не могу записать в файл", не говорящую ничего о реальной причине проблемы.

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

Пока vless. Дальше я думаю будет пофиг - потому как у нас на горизонте стремительно, как тропический ураган разворачиваются "белые списки" - сначала как обычно у опсосов, потом и проводники подтянутся.

"...Я знал, что будет плохо, но не знал, что так скоро..." (С) В. Цой

Считайте, что указание наименования шрифта - это как рецепт на сайте.

Если в рецепте написано, что для выпечки пирожка требуется взять 100 грамм муки высшего сорта (Arial), это не значит, что вы передаёте читателю эту муку, которую вы где-то украли.

Купить, украсть или отобрать у кого-то реальную физическую муку - это уже дело читателя. К тому же вы в своём рецепте даже пишете, что если у вас нет муки высшего сорта, то вы можете взять и любую муку другого сорта (sans-serif), а не красть Arial

> Хочется практиковаться в изучении linux, двигаться куда-то в сторону девопс

Для этого достаточно виртуалки на рабочем компе. Ну или совершенно убитого десктопа или подержанного ноута.
А ещё лучше - в плане "практиковаться в изучении linux" - поставить его на рабочий комп.

Откуда эти завиральные идеи про выделенный комп, да ещё и с каким-то специальным серверным железом, про 8 ядер! - совершенно непонятно. Всё перечисленное ещё 15-20 лет назад работало на 1-2 ядерных серверах в продакшене. А не дома, с нулевой загрузкой.

Решали ровно эту задачу для склада Детского мира. Техническая часть решения состояла в увеличении размера штрихкода (за счет полей), 2мп камеры с матрицей sony exmor r и обозначении на столе цветным скотчем поля обзора камеры, внутри которого сборщик должен был проводить операции с коробкой.
Поле обзора камеры - за счет объектива 5-50мм с лотка освещения на столе составляло около 1×1м. Технически вопрос был урегулирован, но интегратор обломился на стоимости тушки камеры более 40к.

Я просто оставлю это здесь: отображение объектов на реляционную БД - это Вьетнамская война компьютерной науки

Ужасы нашего городка. "испросите ИИ". Это все, на что способна нынешняя молодежь? Рука-лицо...
1) перелить из экселя в базу - задачка простая, день-два, максимум неделя.
2) написать страничку с поиском и выводом результатов, примерно также.
3) а вот далее, сложно, ибо нужно многое уточнять, кто, как куда, зачем, почему.
Ps. Если есть вопросы, контакты в профиле, пишите, пообщаемся,

Проще написать скрипт на php, python и т.п., и уже на уровне ЯП выполнить очистку и прочую обработку.

Дисковое место: сам Битрикс в редакции Бизнес жрёт меньше 1.5 Гб . Остальное зависит от того, сколько у вас картинок и какого они размера.
Памяти как-то мало. Полгига надо отдать под мемкеш или редис, потому что файловый кэш проблемный. Битрикс хочет 384 Мб оперативки на процесс PHP - считайте сами, сколько получится запустить параллельно.
Ещё MySQL отожрёт гига два.
По ядрам:
одно - под MySQL,
одно - под nginx ( ладно, системные процессы сюда же),
и ... ничего не осталось..

10к уников - для простоты можно считать, что они ходят только в рабочее время, то есть 10 часов. То есть 1к уников в час, 1 уник в 3.5 секунды. У Битрикса "эталон" задан как генерация страницы за 0.3 сек - в реальности, конечно больше ( если кто-то станет Вам говорить про автокеширование - плюньте ему в лицо), но вроде вписываетесь.
Сейчас ещё надо учитывать паразитный трафик от нейросетей и всяких парсеров, он может быть очень значительным, но можно его зафильтровать.

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

Вопрос сформулирован по-дурацки, из серии преждевременной оптимизации. "У меня ещё ни базы, ни запросов, ни нагрузки и никогда не будет, но желаю чтобы всё летало!"

Но тем не менее, ответ на него существует. И он гораздо проще, чем все извращения, которые тут наперебой предлагают всякие доброхоты.

Во-первых, увеличить innodb_buffer_pool_size до 80% от доступной памяти на сервере. Mysql совсем не дура, и прекрасно сама подтянет используемые таблицы в оперативку. И вселенская проблема нашего фантазёра будет решена.
Отдельно здесь следует упомянуть случай, когда этому буферу не просто задан недостаточный размер, а жалкие 128 мегабайт, поскольку никто не догадался поменять значение, стоявшее в конфиге по умолчанию.

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