Ипатьев

The manual page at dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Безотносительно к проблеме с неизвестно откуда берущимся кодированием, чем не устроил вариант
simplexml_load_file($url);

У вас каша в голове. И вы все делаете неправильно.
Заменять теги на сущности надо не перед записью в БД, а перед выводом в HTML. Желательно - средствами этого "табулятора", если он это умеет.

Никакой HTML в БД хранить нельзя.
Любое HTML оформление надо добавлять средствами этого "табулятора".
В самом крайнем случае - в ноде, перед выводом

name: '<p>' + entities.encode(result.name) + '<p>'
Хотя это конечно говнокод и кровь из глаз.

Мысль совершенно правильная.

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

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

Поэтому я бы рекомендовал их все равно изучать, но в качестве не основного, а факультативного материала.

Чтобы решить проблему, её надо сначала сформулировать.
В данном случае никакой проблемы нет, есть невнятные страдания.
Ни кода, ни внятного описания проблемы, ни даже пояснения, что имеется в виду под "добавлением" в вопросе нет.

В простейшем случае либо делать один множественный запрос insert, либо заключить отдельные запросы insert в транзакцию

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

Так что в целом можно сформулировать правило, что используется одно или несколько английских слов, подходящих по смыслу.
С одним уточнением: в общем случае в качестве переменной используется подробное описание того, что в ней лежит. Но для очень часто используемых переменных обычно делается исключение, потому что стройные ряды какого-нибудь $userSelectQueryResult выглядят задротством.

И в ваших примерах для PHP тоже просто переводы. Причем не очень удачные.
link - звено - не слишком подходит по смыслу, и почти не используется.
connect - это глагол, а в качестве имен переменных обычно используются существительные. connection подойдет лучше, но совсем длинно.
con - хоть и является сокращением от connection, само по себе означает жульничество. Тоже так себе слово. Поэтому если уж сокращают, то обычно до conn.
Но само по себе "соединение" малоинформативно. Соединение с чем?
Поэтому я обычно рекомендую писать $db - сокращение от database. Тут и коротко, и сразу понятно, о чем речь.

Причем если речь идет об объектах, то всегда можно использовать имя класса в качестве имени объекта.
Например, если вы используете mysqli, то и называйте переменную $mysqli.
Если используете PDO, то называйте переменную $pdo.

$result - подходящее имя, от объекта mysqli_result.
$response обычно употребляется в контексте НТТР., для базы данных не очень подходит.

Причем от использования $result в коде надо уходить. Это промежуточная переменная, которая сама по себе вам не нужна, а требуется для получения реального результата запроса. Ну так вы вполне в состоянии написать функцию, которая сразу возвращает нужный результат, без колупания в промежуточных результатах.

$user = db_get_row($mysqli, "SELECT * FROM users WHERE email=?", [$email]);

и никаких мусорных $result, не говоря уже о том что кода в 5 раз меньше

Изначально интерпретируемые языки преобразовывались в машинный код построчно, то есть каждая логическая строка компилировалась непосредственно перед выполнением. В результате каждая инструкция, заключенная в тело цикла и исполняемая несколько раз, столько же раз обрабатывалась транслятором. В настоящее время такие эффекты редки. Большинство интерпретируемых языков предварительно транслируются в промежуточное представление. Оно представляет собой байт-код. Это набор инструкций по вызову небольших фрагментов более низкоуровневого кода, эквивалентный нескольким командам ассемблера или командам виртуальной машины соответственно. Уже этот код исполняется интерпретатором или виртуальной машиной.

В целом, я считаю что основная причина здесь - это отборный говнокод в переменной $Functions. Я прямо на 100% уверен что каждую строчку оттуда можно помещать в палату мер и весов с пометками "вредные советы" и "дети, никогда так не делайте, за это вам нехороший дядя сделает а-та-та!" Уже за одно только наличие функций redirect() и getString() в одном классе надо автора возить лицом по клавиатуре, желательно механической.

Но если говорить о записи в БД, то причин может быть две.
1. Код вставки вообще не вызывается. Например, $Functions->redirect(); вызывается в случае, если $openid->validate() возвращает false. Хотя понять это можно, только скопировав это адово форматирование в нормальный редактор.
2. Если при выполнении запроса произошла ошибка. Чтобы видеть ошибки mysqli в устаревших версиях РНР, надо добавлять при коннекте строчку

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

и, чтобы два раза не вставать, заодно убрать бессмысленный говнокод try{ }catch(ErrorException $e){ echo $e->getMessage(); }

Ах да, еще третий вариант. Запись о таком пользователе уже есть, и следуя логике кода, в этом случае в БД ничего и не должно добавляться

Есть такой анекдот, "Иван Соломонович, вы или крестик снимите, или трусики наденьте".
Вот он очень подходит к вашему случаю.

Использованный вами код подходит только для файла, в котором на каждой строке лежит неформатированный JSON.
Поэтому надо или писать в файл JSON, не форматируя его,

{"NumberStat":[{"ManNumDetection":[{"AreaID":1,"Channel":0,"EndTime":"2023-04-14 10:59:59","EnteredSubtotal":0,"ExitedSubtotal":0,"StartTime":"2023-04-14 10:00:00"}],"SN":"6M0D6EFPAG24E66","Uploading Time":"2023-04-14 11:00:49"}]}
{"NumberStat":[{"ManNumDetection":[{"AreaID":1,"Channel":0,"EndTime":"2023-04-14 11:59:59","EnteredSubtotal":0,"ExitedSubtotal":0,"StartTime":"2023-04-14 11:00:00"}],"SN":"6M0D6EFPAG24E66","Uploading Time":"2023-04-14 12:00:49"}]}

или, как рекомендуют в других ответах, переформатировать эту стену текста как единый JSON массив

Не должно у вас изменение сущности в одном приложении влиять на сущность в другом.

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

Какая проблема, чтобы Client сходил в Order, получил идентификатор созданного заказа и дернул Billing?
Зачем во всех этих трех сервисах делать тройное дублирование сущностей?

1. У страницы делаем расширение .php вместо .html
2. Внизу пишем <?php include 'footer.php'; ?>

Всех дел на 30 секунд.

Ну, вариант "в лоб" это

select * from table where date >= n and id not in (...) order by date limit 1000

где n - это последняя дата с предыдущей страницы, а ... - это список id на ту же дату с той же страницы.

Но как правильно пишут в комментариях, если пагинация начинает тормозить, то надо что-то в консерватории менять. И например разбивать не по 1000 строк, а по дате.

Здесь, как всегда, набежала куча народу, которая слышала звон, да не знает где он. И думает, что php-fpm - это, видимо, такой типа модуль для nginx.

php-fpm, на данный момент - это единственный (ок, ок, из широко распространенных) вариант использовать РНР на веб-сервере. С любым сервером НТТР. И нет, php-fpm не имеет никакого отношения к Nginx, это совершенно отдельный менеджер процессов, который работает с любым веб-сервером.

Поэтому надо уточнить, не стоит ли он уже. Потому что устареший вариант конфигурации Апач + mod_php был объявлен нежелательным уже лет 5 тому назад. И хотя работать будет, но во-первых, говорит о квалификации установителя, а во-вторых, под большой нагрузкой будет ложиться. Поэтому желательно использовать именно php-fpm, а уж с Апачем или Энжинэксом - это скорее вопрос вкуса в данном случае.

Если же ожидается 10 пользователей в день, то без разницы, можно оставить как есть.