FanatPHP

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

Большинство складывателей букв на РНР об этом не задумываются вообще, и очень хорошо что тебе пришел в голову этот вопрос. А ответ на него очень простой:

Проверять обращения к БД не нужно вообще

(за исключением нескольких специальных случаев, когда есть определенный сецнарий обработки ошибки)
Если же такого сценария нет, то никак проверять не нужно. Просто потому, что обращения к БД ничем не отличаются от любого другого кода.
И поскольку ты не проверяешь каждый include или там оператор деления, то не нужно и проверять запросы к БД. Их надо оставить в покое. И первый, и каждый по отдельности, и все 5 разом.

А вот что нужно сделать - это договориться с РНР, чтобы он сам сообщал тебе об ошибках в запросах. Для mysqli надо написать перед коннектом

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

Для ПДО при соединении выставить в настройках соединения

PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION

Всё. Больше ничего для обращений к БД делать не надо.

А вот обработчик ошибок, общий для всего кода, а не только для работы с БД, настроить желательно.
Чтобы AJAX-скрипт подписки получал соответствующий НТТР статус при любой ошибке, которая может возникнуть на сервере.
Ну и разумеется AJAX-скрипт подписки должен проверять НТТР статус, и обрабатывать ответ только если статус= 200
Пример обработчика можно посмотреть здесь

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

*На самом деле в транзакцию имеет смысл заключать только запросы, изменяющие данные. То есть все, кроме первого.

Соотсветственно, если ПДО настроен на выброс исключений, то при ошибке запроса
- пдо выбросит ислючение
- которое будет поймано обработчиком ошибок
- который выведет код ошибки и завершит работу РНР скрипта
- при завершении скрипта РНР закроет соединение с БД
- БД при закрытии соединения автоматически откатит незавершенную транзакцию

причем без обработчика ошибок будет всё то же самое, только клиенту уйдет код не 500 а 200

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

1. выставить для ПДО режим исключений
2. перед первым запросом написать $pdo->begin();
3. после последнего запроса написать $pdo->commit();

Первый вариант, разумеется, вообще ни о чём.

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

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

Как у тебя только в глазах не рябит от всех этих знаков препинания
1. Не HTML писать внутри РНР, а наоборот - РНР внктри HTML.
2. Использовать оператор сведения с null
3. Экранировать вывод по умолчанию
т.е

<tr class="tableGrey">
    <td>Фактический адрес</td>
    <td colspan="4"><?= htmlspecialchars($callCompanyData['result']['UF_CRM_1587463057321']) ?? ' ') ?></td>
</tr>

3. Научиться пользоваться шаблонизатором Twig, т.е.

<tr class="tableGrey">
    <td>Фактический адрес</td>
    <td colspan="4">{{ callCompanyData.result.UF_CRM_1587463057321 ?? ' ' }}</td>
</tr>

Чтобы записать этот вывод в переменную надо пользоваться функциями буферизации вывода

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

В текущем же виде ответ только один - помазать зеленкой добавить индекс
если индекс есть, и поиск идет по полному совпадению, то смотреть, влезает ли индекс в память
Если поиск идет по частичному совпадению - то выносить его в отдельный сервис, sphinx/elastic

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

потому что перезапускаешь ты веб-сервер а надо - РНР

DateTime::createFromFormat()