Vitsliputsli

В 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.... Представления они для человека. Тип задается при создании, не думаю, что его можно поменять, т.к. разные типы - это совершенно разные структуры.

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

Любая видеосвязь с автоответом, например в Skype можно настроить автоответ на звонок.

Используйте регулярные выражения, в зависимости от вариативности текста, от обобщенного:
/<b>(.*)<\/b>/
до более узкого:

/\(длина, ширина, высота\): <b>(\d+ x \d+ x \d+)<\/b> см. /