Vitsliputsli

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

Я бы посоветовал ничего не читать и не тратить впустую время. Оценка времени разработки никогда не бывает точной и с этим нужно смириться. Декомпозиция вещь хорошая, но тут теория вряд ли поможет, только опыт разработки.
Любая попытка более точной оценки - это устранение неопределенностей, для этого, например, разбивают на более мелкие задачи в которых точно уже известно что делать и кажется что все контролируешь. Но, оценка никуда не делась и она всегда строится на "похожих" задачах, которые уже делались. Только вот если мы говорим про нормальную разработку, то там это не работает, совсем... Если действительно похожая задача реализована, значит основной функционал уже есть и нужны только минимальные правки, а значит вторая задача будет стоить несравнимо меньше. Другой момент, действительно со стороны может показаться что есть похожие задачи и на них всегда тратится похожее кол-во времени, но в какойто момент времени окажется что следующая "похожая" обойдется в 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?

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

Коды в доке: https://www.opennet.ru/man.shtml?topic=stat&catego.... Представления они для человека. Тип задается при создании, не думаю, что его можно поменять, т.к. разные типы - это совершенно разные структуры.

Можно, но сперва изучите вакансии, чтобы иметь представление о рынке.
Несмотря на повсеместный пиетет перед этой профессией, она вполне себе обычная. Это труд схожий с обычным тестированием, скурпулезный и монтонный. Как и в разработке, на первых парах в нем нет места для творчества, и это изменится лишь если повысите квалификацию и устроитесь в компанию, которая поощряет исследования.
Знания нужные пентестеру те же, что и разработчику. Так как безопасное ПО создает именно разработчик. Другое дело, что на практике разработчики знают мало, из-за узкой специализации и игнорирования вопросов безопасности. Так, скорее всего, по фронту вам дадут только знания безопасности во фронте, а это очень маленькая часть. Да, и на беке зачастую многие вопросы безопасности игнорируются, тупо изза незнания. Поэтому хотя эти знания и необходимы, в разработке с вас будут требовать чаще иное, например структуризация кода, которая пентестеру не интересна.