ThunderCat

Первое что нужно сделать

$link = mysqli_connect('localhost', 'user', 'pass', 'db_name');
    $query = "SELECT * FROM `cpl_credits` WHERE `bank_id` = $bank_id";
    var_dump($query);
    $result = mysqli_query($link, $query) or die(mysqli_error($link));

Копируем строку запроса и идем в пхпмайадмин, вставляем запрос напрямую в поле запросов, смотрим как и что сработало. В случае

даже так ничего не выбирается:
SELECT * FROM `cpl_credits`

проверь права текущего пользователя мускуля к этой таблице.

php.net/manual/ru/function.date-default-timezone-s...

Зависит. Если у вас как-то организовано по объектам и в частности есть отдельный объект дб - то проблем нет, если какакод с разбросанными по проекту запросами в 40 файлах - тады ой.
Хотя можно пробежать поиском по файлам на предмет запросов и понатыкать там логгеров.

бэкапы почаще, все остальное опционально.

Поддерживаю longclaps, вы что, алиекспресс админите? откуда в таблице товаров 5М строк, вы что, спички поштучно учитываете? Это номер раз, второе - если фильтры такие забубенные - делайте в 2-3 запроса через бэк, что у вас там, пых, нода, джанга, ограничивайте по уму количество товаров в первой выборке по самому быстрому индексу и самой ограничивающей выборке, например все товары выбранной категории, далее филтр только на результат выборки по типу id in(1,2,3,4). И все же скажите, не мучьте, ОТКУДА СТОЛЬКО ТОВАРОВ БЛИН, я ж не засну теперь...

то есть запрос по типу select * from structure where parent_id = 6 занимает 6 секунд?
Какой запрос используете, какая структура у таблицы structure?

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

https://redis.io/topics/notifications

UPD: я тут перечитал ваша каша, видимо идея у вас такая: редисом храним быстрое нарастание просмотров, раз в какое-то время кидаем в мускуль чтобы не похерить в случае жопы.
Если так, то зачем нам время смерти? Пишите в ключ до упора, раз в какой-то промежуток скидывайте в мускуль, при отсутствии ключа по запросу (например был сбой и редис помер) - лезем в мускуль, достаем сколько было, суем в редис и мучаем его дальше в том же режиме. Имхо кучу ресурсов сэкономите на создании/убивании ключей.

происходила сверка информации - данные обновлялись, а те, которых нет - добавлялись?

insert ... on duplicate key update

добавляются\убираются какие-то позиции

каким образом удаляются? передается ид и модификатор удалить?

вы определитесь что вам нужно, а то как то не понятно что в итоге в приложение должно попасть?
Если нужно только имя босса - тогда зачем в первом запросе выбирать сумму?
Если нужно и сумма и ид компании и имя босса то join on то что вам нужно.
Если с джоинами тупите - выберите в приложение и оттуда уже дайте второй запрос с чистым ид.

Если делать простой запрос LIKE '%%

начнем с того что это самый неправильный метод работы с текстом. То есть его используют только когда по другому уже совсем никак.
Во первых - какого рода тексты хранятся в записях? Длинна, тип поля.
Сильно подозреваю что фултекстсерч может резко поменять ситуацию.

UPD: https://habrahabr.ru/post/25646/#comment_641326 что как мы видим на несколько порядков быстрее.

Студент успешна удалена

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

можно как нормальные герои - в обход.

public function sqlProt($str)
        {
            global $pdo;            
            return $pdo->quote($str);
        }

Глобал? Серьезно? А где вы его создали в глобальном пространстве? (подсказка - dbh)
Зачем quote(), если есть prepared statements?
Мой совет - посмотрите готовые библиотеки, для начала простенькие. Хотя бы поймете что и как делать.