Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

выражение "забронзоветь" не имеет отношения к PDO. Это всего лишь характеристика человека, который верит в собственную непогрешимость, а любые нестыковки объясняет непонятливостью собеседников, "багами" в языке или глупостью его разработчиков.

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

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

выкладки - это не код, а выводы, расчеты, умозаключения. Они у вас неправильные. Вы смотрите в документацию (правильную), на логи (очевидные) а выводы делаете неправильные. Про это даже анекдот есть:

Опыт №1: берем таракана, отрываем две ноги, свистим, таракан убегает.
Опыт №2: отрываем таракану четыре ноги, свистим, таракан убегает.
Опыт №3: отрываем таракану все ноги, свистим, таракан на месте.
Вывод: таракан без ног не слышит

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

Akina, чтобы у человека наступило, этот человек должен сомневаться в первую очередь сам в себе, проверять свои выкладки. Так работает научный подход. А у нашего героя ровно наоборот - кругом дураки, а он непогрешимый гений в белом пальто :)
Вот и сейчас: у него есть все данные, чтобы разглядеть элементарное объяснение наблюдаемого эффекта, когда поведение как раз должно отличаться. Причем эффекта стороннего, который наблюдается очень редко. Потому что все люди выполняют запросы нормально, как описано в мануалах.
Но чванство убивает мозг. Чувак забронзовел. А когда ты перестаешь сомневаться в себе и свои проблемы начинаешь списывать либо на тупость собеседников, либо на несуществующие "баги" в языке - тут уже голова перестаёт работать...

Присвоить значение массива переменной?

Как мне по другому идентифицировать/обратиться к конкретному имени?

ЗАЧЕМ? Что вы по этому имени хотите получить? Узнать, есть ли на него дата, или нет?

Присвоить значение массива переменной?

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

Экранирование sql запросов, достаточно ли функции?

Рука-лицо. Комментарий из серии "угадал все буквы, не угадал слово".

Присвоить значение массива переменной?

во-первых, не переменным, а элементам массива. Перечисляемые значения пишут в массив, а не в отдельные переменные
во-вторых, я правильно понимаю, что вам надо элементарно получить уникальные значения из этих массивов?

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

Вот он и он пишет, что чтобы получить ошибку, результат надо получить. А не выкидывать, как это делаете вы.
Давайте уж я вам разжую, чтобы вы больше не отнимали время у занятых людей.
ваши инсерты работают потому что в режиме эмуляции
почему происходит ошибка, вам разжевали на гитхабе - потому что вы не запросили результаты своих запросов, и они остались ждать на сервере. чтобы ошибки не было, эти результаты надо либо получить, либо выкинуть (при этом смысл cделать запрос, но не проверять его результат от меня ускользает).
при этом если результат не запросить, то ошибка и не будет в нем отражена.
совершенно очевидное поведение, когда локальная переменная уничтожается по завершении работы функции (которое пытаетесь формулировать через какой-то детский лепет про "параллельное выполнение" ) как раз это и делает: по завершении работы функции всем её переменным делается unset. чем и объясняется все загадочное волшебство, происходящее в ваших примерах.
при этом куда проще выполнять запросы по одному: тогда не нужно проверять результат каждого вручную, плюс не зависеть от режима эмуляции.

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

Боже, я и подумать не мог, что вы реально побежите писать нелепый баг-репорт в РНР. Судя по всему, именно его вы называете словом stackowerflow. И разумеется, в своей манере переврали сказанное там, причем с точностью до наоборот. Там написано не будет отражено, а вы мне толкаете что будет.

Стоит ли хранить изображения base64 в БД?

rakas, два вопроса
1. вас посетители сайта никогда не били за такой адов трафик?
2. а почему так много? Там карта звёздного неба в разрешении 144 мегапикселя?

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

В случае PDO SQL запроса не через prepare() - вроде закрывает.

Ну то есть получать запрошенные данные в случае PDO SQL запроса как бы и не надо. Выполнили, и сразу можно закрывать. Всё логично.

Стоит ли хранить изображения base64 в БД?

2-4 МБ - это все картинки или одна?

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

почему мы не падаем с ошибкой прямо на этом запросе?

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

если бы мы упали, как мне объяснили на StackOverflow, это было бы отражено в результате.

как обычно, там соврали

Таким образом, проблема в том, что дефолтный режим запросов - unbuffered query

здесь абсолютно не при чём

сам не закрывает соединение

с какого перепугу-то он будет закрывать

А вместо этого мы свели вопрос к тому, что я плохо от инъекций защитил код.

Это вы и свели, начав двигать свои гениальные идеи по защите от инъекций.

В чем нарушение синтаксиса в данном запросе? Как его исправить?

За таким, что по логике Джордж Клуни может оставить отзыв о жилье только если он его бронировал, а не просто с улицы пришёл. И отзыв будет привязан к конкретной брони. Из которой уже можно получить и пользователя, и жильё. А нет брони - нет и отзыва.
Соответственно, user_id здесь избыточно, поскольку оно уже есть в таблице бронирования. Как и номер комнаты.
То есть задача именно по жилью и юзеру найти бронь, и подставить её в отзыв.
Впрочем соглашусь, что в вопросе ничего этого нет.

А почему CROSS, а не INNER?

В чем нарушение синтаксиса в данном запросе? Как его исправить?

По условию задачи надо использовать CTE? или два запроса?
Можно увидеть полный текст условия?

В чем нарушение синтаксиса в данном запросе? Как его исправить?

И забудьте про SELECT COUNT(*) + 1. Это стрельба себе в ногу на поражение. прочитайте для чего служат уникальные идентификаторы и как ими пользоваться.

В чем нарушение синтаксиса в данном запросе? Как его исправить?

INSERT INTO Reviews (rating, reservation_id) VALUES (5, 
  SELECT id FROM Reservations
    WHERE user_id = (SELECT id FROM Users WHERE name = 'George Clooney')
    AND room_id = (SELECT id FROM Rooms WHERE address = '11218, Friel Place, New York')
)

Такой запрос не работает?

В чем нарушение синтаксиса в данном запросе? Как его исправить?

И непонятно, зачем здесь CTE.

В чем нарушение синтаксиса в данном запросе? Как его исправить?

Зачем вы пытаетесь выполнить два запроса одновременно?
Запросы выполняются по одному.

PHP Fatal error: Allowed memory exhausted при загрузке JSON в API?

Автор не умеет писать, а вы не умеете читать. Но беретесь строчить ответы
Проблема у него при получении данных в API.
До "беру с диска" дело не доходит. Он написал это от балды, просто к слову пришлось.
Если читать вопрос предназначенными для этого органами, то это становится очевидно.

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

PHP Fatal error: Allowed memory exhausted при загрузке JSON в API?

Ну вот JhaoDa гораздо лучше вариант предложил. Хотя я все равно не понимаю, зачем здесь application/json, если API запроса как такового все равно нет.