Vitsliputsli

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

1Гб это очень мало для современных дистрибутивов, тем более для сервера с СУБД. apt check в Ubuntu (не знаю как в других) любит жрать память без причины, просто так, и никто это не чинит уже более 10 лет. А когда память заканчивается неизвестно, что попадет "под нож", вполне может и СУБД, как самый жирный процесс. Поэтому проверьте когда в последний раз запускали СУБД.
Если увеличить память никак нельзя, попробуйте полностью отключить запуск apt-check. Если у вас обновления автоматические, то перевести их на cron.

сбрасывается индексное значение (auto_increment) до 1

Таблица постоянно чистится, и в этот момент она пуста?

На практике не делал, но чисто теоретически, поле id подразумевает что для него построен индекс primary key (иначе зачем оно нужно). В PostgreSQL primary key в партиционированной таблице - это индексы каждой отдельной партиции, т.е. если мы партиционировали не по полю id (а скорее всего так и есть), то при попытке обращения по полю id нам нужно отдельно пройтись по каждому индексу каждой партиции, а это уже не так весело как по одному индексу. А если партиции сделаны достаточно маленькими и их много, то фуллскан одной партиции скорее всего будет быстрее. А если контроль уникальности вынесен в приложение, то можно обойтись вообще без primary key, даже натурального, тогда и при вставке не нужно сканить все эти индексы.

При применении миграций после переключения на новый код вам придется постоянно в коде проверять версию базы и держать код работы с разными версиями. Иначе - постоянная некорректная работа во время деплоев.
Гораздо проще применить миграции и переключиться новый код. Обратную совместимость базы данных поддерживать легче (если база - это данные, а не хранимые процедуры), поэтому откатить код можно будет без проблем, а откатывать миграции скорее всего даже не потребуется.
Самый простой способ тестирования для отката - это контроль ошибок реальной работы и скрипты health check по основным метрикам, их будет достаточно.

чтобы мне такого почитать про оценку времени вообще и про декомпозицию задач в частности?

Я бы посоветовал ничего не читать и не тратить впустую время. Оценка времени разработки никогда не бывает точной и с этим нужно смириться. Декомпозиция вещь хорошая, но тут теория вряд ли поможет, только опыт разработки.
Любая попытка более точной оценки - это устранение неопределенностей, для этого, например, разбивают на более мелкие задачи в которых точно уже известно что делать и кажется что все контролируешь. Но, оценка никуда не делась и она всегда строится на "похожих" задачах, которые уже делались. Только вот если мы говорим про нормальную разработку, то там это не работает, совсем... Если действительно похожая задача реализована, значит основной функционал уже есть и нужны только минимальные правки, а значит вторая задача будет стоить несравнимо меньше. Другой момент, действительно со стороны может показаться что есть похожие задачи и на них всегда тратится похожее кол-во времени, но в какойто момент времени окажется что следующая "похожая" обойдется в 10 раз дороже. Поэтому если где-то похожие задачи всегда стабильно стоят одинаково, то скорее там не разработка, а набор текста.
Если про правки "в сильно незнакомом коде", то даже не пытайтесь, здесь неопределенность зашкаливает. Такой код требует предварительно изучения, и не важно какая задача, она может решаться как добавлением 2 строчек, так и переписыванием всего и вся.
"возможно предварительно поисследовав", как только вы употребили слово исследование, никакие оценки здесь уже не применимы. Исследования не оценивают, на них выделяют время, когда время закончилось решают нужно ли еще время или бессмысленно копать в эту сторону.
Это все, конечно, несколько утрировано, но, на мой взгляд все что требуется со стороны разработчика (а я так понял вопрос именно с этой стороны) это просто давать оценку задачам, а затем обращать внимание на аспекты которые потребовали много времени, но которые упустили при планировании.

Прям очень по-разному, но чаще очень редко или никогда.
Вообще, нагрузочное бывает 2х видов:
1) тестирование релиза на возможную деградацию производительности;
2) тестирование запаса прочности приложения (это когда повышаем нагрузку, пока все не упадет).
И еще важно где применяется:
а) где деплой полностью контролируется, т.е. на свои серверы;
б) где сборка разворачивается где-то на удаленных серверах 3ми лицами.
Нагрузочное 1 типа для варианта "б" проводят для каждого билда, вряд ли есть исключения, иначе чревато. Для варианта "а" часто "забивают" вообще на этот тип тестирования. Причины просты, прям какаято сильная деградация будет заметна при прогоне обычных тестов, просто по их замедлению. А если тесты еще идут параллельными потоками, то и некоторые блокировки можно отловить. С другой стороны, если чтото не так, то деплой полностью контролируется и можно всегда откатиться. И тут реально в первую очередь лучше озаботиться blue-green серверами и плавным переключением трафика, а потом уже нагрузочным тестированием. Да и чаще, это будут какието медленные деградации, которые отловит мониторинг и опять же либо будет время поправить, либо можно откатиться.
Нагрузочное типа 2 делают очень редко (например 1-2 раза в год), т.к. штука затратная, и опять же мало где его вообще встретишь, только там где стабильность очень важна и/или пиковая нагрузка может в разы отличаться от стандартной.

В logfile.log ничего не будет, вы же ничего не выводите в поток.
Проверяйте логи php, если там ничего нет, проверяйте как вы их пишете (если не меняли ничего в логировании, то должны писаться).
Если логи работают (эмулируйте fatal error и посмотрите), но ничего в них нет, значит чтото внешнее убивает процесс php не давая ему возможности записать лог. Обычно так жестко поступает oom killer.

Как выкрутиться, чтобы prepare выполнять только один раз?

Prepare подготавливает план, нельзя подготовить план без таблицы.
Тем не менее, prepare будет выполняться 1 раз, но для каждой запрошенной таблицы.

А в чем собственно сложность? Prepared statements это всегда как минимум на 2 запроса больше, чем без них, если просто считать запросы. Хотя колво запросов и скорость не везде зависимы. Да и pdo по-умолчанию предпочитает их не использовать, заменяя своей эмуляцией.

Самый правильный вариант - отключаться, если соединение не используется. Правильно, т.к. не используем ресурсы для поддержания ненужного соединения, ни на клиенте, ни на сервере. И не ловим эксепшены.
И только если ну никак нельзя это контролировать, тогда реконнект по эксепшену.

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

do {
    $path = [key($array), $link = current($array)];
    while (isset($array[$link2 = $link])) {
        $link = $array[$link2];
        unset($array[$link2]);
        $pathPos = array_search($link,$path); // более для понятности, для длинных колец эффективнее хранить только ключи и искать по ним
        if (false !== $pathPos) {
            var_export(array_slice($path,$pathPos));
            break;
        }
        $path[] = $link;
    }
} while (false!==next($array));

Создать зависимость можно только 2 способами, получив объект изнутри или проведя инъекцию снаружи. Если изнутри, то так или иначе понадобится синглтон, если снаружи, то ктото снаружи должен контролировать передачу одного и того же объекта во все нуждающиеся объекты.

1. Изнутри. Очевидно просто инстанцировать объект - это очень плохой вариант. Более менее нормальный вариант, это сервис локатор, с методом возвращающим нужный объект работающим как синглтон (т.е. не нужен прям класс синглтона, только метод который проверяет существует ли объект). Выглядит это не очень, синглтон и сервис локатор не считают хорошим решением. Из минусов статичное обращение к сервис локатору создаст проблемы для подмены объекта. Для разных подключений вы можете создать отдельные методы сервис локатора или разрулить в одном методе динамический выбор. Реальная проблема - тестирование, вы не сможете мокировать объект работы с БД. Но, можно это сделать ухищрениями, сделав ленивое подключение, и метод подмены объекта БД, хотя придется этот метод тащить в каждый класс. Как вариант, делать инъекцию объекта сервис локатора. Но остается другой большой минус, сервис локатор "гвоздями прибит" к большинству классов и вам придется его везде таскать, т.е. о красивых компонентах без странной зависимости от сервис локатора можно забыть.
2. Снаружи. Оптимально, и считается трендом - инъекция нужного объекта в конструктор. Будет ли это делать DIC или чтото иное не имеет значения. Не нужно таскать какието дополнительные сервис локаторы. Но данное решение имеет тот же минус, что и п.1, вы не сможете подменить объект на другой при мокировании:
public function __construct(PDO $db)
внедряемый объект обязан быть классом PDO, если хочется чтобы мок просто подсовывал одни и те же значения нужно менять на интерфейс, тогда моку достаточно выполнять требования интерфейса. Но, если ваш DIC использует автоматическое определение требуемых объектов по структуре конструктора, то использовать интерфейс не получится.

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

Парсер просто последовательно читает текстовой файл, он ничего не знает о выполнении кода, но знает синтаксические правила языка. Если речь про интепретатор, то он выполняет код последовательно, но в нем есть команды перехода к различным участкам кода, от простейших условных и безусловных до функций и объектов с методами.
Поддержки асинхронности из коробки в php нет, но есть специальные библиотеки для этого, например ReactPHP. Если же говорить про чистый php, то в нем есть несколько асинхронных функций (например multi_curl), но правильнее сказать, что они неблокирующие, а асинхронность придется воплощать вручную, периодически передовая управление этим функциям.

никаких ошибок не выдает... Там просто в моменте обрывается и всё

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

Без этой информации можно лишь гадать, варианты:
1) скрипт выполняется корректно (например, у вас не 8к записей, читаете не из той БД, не с теми параметрами и т.п.);
2) происходит ошибка, но мы ее не видим (смотрим не в тот лог, гдето присобачен обработчик, который перехватывает ошибки и подавляет их сообщения, и т.п.);
3) скрипт действительно аварийно прерывается без каких либо сообщений об ошибках (значит чтото дает команду на это, если самовредительством не занимались, то остается только oom killer, но вряд ли у вас безлимит на память php, и то что закончилась память вы бы заметили, так что очень маловероятно);
4) неведомая хрень (баги в php, в ОС и хз что еще, еще менее вероятно, чем п3).

Почему для работы с массивами более производительней сохранять данные и перезаписывать их на другое значение, а не удалять?

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

И каким образом Object.defineProperty нам ускоряет получения значения

Речь про то, что автор накой-то хочет сделать обращение к объекту кольцевого буфера через нотацию query[0], как в массиве. В итоге делает только для 0, если для всех, то придется подменять методы, а значит в них будет больше действий, а значит будет медленней.

Приведите, пожалуйста, простой пример, как, именно «заменить» ключ (числовой на строковый) в массиве.

Если не вникая, на кой это нужно, то так:

unset($array[1]);
$array['first']=1;

Для массивов есть итератор foreach и не только, зачем вам ArrayIterator?