ThunderCat

var_dump();
print_r();
echo
XDebug
Узри и познай дзен!

PS: Я посмотрел - сломал глаза и мозг, что вы пытаетесь сделать? Что за бредовые значения в базе лежат? Что с чем вы сравниваете?Вообще как это работает хотя-бы примерно понимаете или тыкаете палочкой пока не зашевелится?

Ищем за вас
пару ссылок:
тыц
дыц

делаешь ключ составным из полей post_id, user_id, ip_address, session_id, created_date, делаешь уникальным, и при вставке делаешь инсерт ор апдейт он дупликэйт. Немного черезпопно, но задачу вроде решает.

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

Если уже тормозит база/код, все - без рефакторинга в любом случае не обойтись, надо брать и делать.

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

1) Где описана функция getHoroscope ?
2) funktions/funktions.php - че правда, прям funktions? В видео так и называют? Клевое наверное видео! )
3) Настройте вывод ошибок и варнингов, для разработки уровень ошибок должен быть E_ALL. Лучше настроить в php.ini.
4) Все представленные выше куски кода ни к задаче ни к проблеме отношения не имеют.

bigdump, но файл дампа все равно придется залить на хост, через фтп или файл менеджер в панели управления.

ORDER BY RAND(), это не самая быстрая операция, однако если запрос будет выполняться часто - его можно ускорить

1) Есть лог, куда пишутся все ошибки, ЕГО НАДО СМОТРЕТЬ, искать решение на уровне "что-то не работает, надо тыкать пальцем в разные места" глупо и неэффективно.
2) Если лог не ведется(что конечно странно, но возможно) то логи ошибок нужно включить, вывод можно не включать.
3)

type_ed = explode(",", $n['threat_type']);
$type_edit = '';
foreach ($type_ed as $type_edd)
{
        $ttt = $db->query("SELECT * FROM `type` WHERE `id`='".$type_edd."'")->fetch_assoc();
        $name_type = $ttt['type'];
        $type_edit.= "$name_type,";
       
}

что то в этом куске неверно, запросы в цикле есть зло, и тут явно напрашивается более другое решение, навскидку можно было сделать сразу 1 запрос где `id` in ($type_ed), хотя подозреваю что это криво организованный список категорий, записываемый строкой с запятыми в качестве разделителя. Это г*нокод, по этому и тормоза и глюки.
4) Если проблема во времени выполнения скрипта то можно запускать в консольном режиме в отдельном процессе в бэкграунде, что для разовых задач нормально.

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

Вариантов несколько, и все они не решат проблемы мгновенно.
1) Бить морду продавцу и заставить либо деньги вернуть, либо тюнить до нормальной работы. Это в случае если продавец знал какой объем данных будет на сервере обрабатываться.
2) Самостоятельные действия. Тут интереснее конечно, особенно если вы не очень в теме.
а) Переносим данные/код на локальный сервер и ищем проблемы на уровне производительности железа. Если на локале все работает шустро - скорее всего не хватает ресурсов хостинговых машин/виртуалок.
б) Подключаем системы кэширования. Это может серьезно ускорить работу, но, как и любое решение, имеет ряд минусов.
в) Тюнить код руками - в вп это конечно не так просто и прозрачно, больше похоже на ремонт канализации, затопленной толстым слоем ... отходов.
В целом - сочувствую, вам предстоит квест )

1) для начала var_dump($_POST), и скорее всего с именами переменных у вас будет лажа
2) Лажа скорее всего обусловлена строками

<select name="type_users" id="type_users">
    <option name="server1" value="server1">CRMP-RP</option>

, где option name="server1" нифига не валидная строка, имя задается только в теге select.

как заметили выше RBAC или ACL

query builder

print_r($db_defqq); Смотреть, много думать...

выбираем все файлы из папки в массив, далее

foreach ($filenames as $filename){
    $res = $db->selectOne("SELECT `id` FROM `images` where `path`='$filename'"); // смысл получить запись 
//из бд(или false в случае отсутствия)
    if(empty($res)) deleteFile($filename); //думаю deleteFilename() сами напишете
 }

делать одну таблицу и хранить там данные в виде serialize

можно лишь в том случае, когда поиска/выборки по свойствам загнанным в сериализованную строку (вместо полей) производиться не будет, т.е. это аля "выбрать все и показать на сайте, поиск не нужен". В противном случае записи параметров стоит вынести в отдельные поля таблицы связей и навесить индексы куда надо. Вынести параметры в отдельную таблицу, в таблице связей же использовать индексы из нее.

на функцию запроса пропишите debug_backtrace с выводом в файл. У вас же есть отдельная функция на построение /выполнение запроса?

в екселе задается знак разделения разрядов, это настройки интерфейса, в мускуле тип данных с плавающей точкой не меняется. Отсюда вывод - два клика в екселе проще чем обработчик на любом ЯП. Тут например обсуждали этот вопрос.

беда, если для оплаты вы передаете цену ) через пост передается только ид товара и количество, на сервере уже берется товар из бд и по нему заполняется цена, иначе я у вас там назакупаю мерседесов по 20 копеек )