ThunderCat

0) Проверить лог ошибок или добавить в код выше

ini_set('error_reporting',E_ALL);
ini_set('display_errors', 1);

и убедиться что ошибок выполнения нет. Естественно, подключение должно быть настроено на вывод ошибок. Так же убрать бессмысленный биндинг $stmt->execute(['id'=>id]);, где внутри даже не переменная, а какая-то фигня...
1) Проверить запрос в консоли или в phpmyadmin
2) В случае если запрос ничего не выдает - удалить строки INNER JOIN category ON category.id=post.cat_id, выполнить запрос
3) Если выдает что-либо, значит таблица с категориями пострадала, проверить выведенные посты на номер категории, и посмотреть что стало с этими записями в таблице category.
4) Если не выводит - повторить пункт 3 со строкой INNER JOIN users ON post.user_id = users.id, со всеми вытекающими.

Я так понимаю, клиентов у вас в год копится больше чем позволяет проиндексировать int?
Тогда во первых поздравляю со столь успешным бизнесом.
Во второых - чем обусловлено такое гениальное решение (ну, кроме незнания о существовании bigint)?
Ну и в третьих - при таких оборотах можно было бы позволить себе нанять нормального программиста, или даже архитекта...

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

Гуглите построитель запросов PHP. Или используйте готовые фреймворки, куда они уже встроены.

group by + count()

Для начала, надо видеть ошибки, для этого:

// Mysql connect
$opt = [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION];
$conn = new PDO(
    "mysql:host=".$settings['db']['host'].";dbname=".$settings['db']['name'].";port=".$settings['db']['port'].";",
    $settings['db']['user'],
    $settings['db']['password'],
    $opt
);
...

После этого смотреть что вылазит в ошибках.

JSON это строка. Формат хранения позволяет хранить много значений разного типа в одной ячейке. Очевидно что активная работа с таким форматом будет не эффективна, так как каждая строка по сути может содержать совершенно различный набор внутри себя, что не есть хорошо для поиска.
С другой стороны, данные не критичные к поисковым выборкам (то есть по которым не будет производиться сравнение, объединение или сортировка) по сути строки, и на производительность влияют мало. А что нужно конкретно вам - из вопроса не ясно.

Маленькое уточнение к предыдущим ораторам, ответы которых дают целый спектр годных решений.

Вполне возможно что таблица которая вам нужна (пользователи?) не занимает много места и, на самом деле, является лишь малой частью файла, а остальное ненужные данные. Стоит проверить данный тезис и далее выделить в отдельный файл скрипт загрузки только этой таблицы. Как работать с этим куском уже дело вкуса - искать как в файле или импортировать в бд. ИМХО бд в этом плане удобнее и практичнее.

груп бай коде
ордер бай дэйт деск

https://www.google.com/search?q=python+mysql+prepa...

SELECT v.product, , v.link FROM v_product v WHERE v.id = 5463 ORDER BY v.product ASC;
SELECT i.id as info_id, i.link_to_site FROM infograph v WHERE id = 5463;
SELECT i.info, description, title, price, first_letter FROM baseinfo v WHERE id = 5463;

Во первых - куда делся префикс алиаса в условии во втором запросе и почему сам алиас как в первом, хотя используется какой-то i? И тот же вопрос про третий запрос. Еще и в первом 2 раза выбран v.link... Короче бардак с самими запросами для начала пофиксить бы...
Во вторых - почему у вас айди в 3 разных таблицах один и тот же? Может это не первичный индекс, а внешний ключ, тогда он должен иначе называться. И где тогда сам первичный ключ?
В третьих - сделать нормальную структуру, ну и тогда можно объединить их через внешний ключ, с указанием что один из них (базовый) равен 5463.

Похоже что сам синтаксис вам предельно незнаком, и вы просто пишете рандомные строки...

С запросом все ок, а вот с тем кто составлял могу сказать что не так:
Если не читать документацию, а ориентироваться на свою "и так понятно" логику, то ничего хорошего не выйдет.
Хинт: Помогите Даше найти логику в строке:
WHERE name='Nikolai' AND name='Katerina'

в пхп передаются параметры прошлого запроса (пофиг как, через куки, гет запросом, божественным откровением или сессионной переменной - не суть), а пых вычисляет новое смещение и передает его в запрос вида limit 10, 5 (про лимиты читать в доке)

group by question_ и groupconcat

Heinemann,

Хорошо, но почему хрень?

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

Может, есть какие-нибудь методы или способы, которые помогли бы найти проблему?

Для начала - попробовать на другой машине, например на самом дешевом хостинге. Вангую, что там будет все ок, и проблема в локальной машине.
Что можно сделать:
1) Сменить драйвер на PDO
2) Переставить пхп и мускуль, вполне возможно что у тебя какой-нибудь кривоватый опенсервер со старыми версиями всего на свете, пробуй нормальную установку компонент из официальных источников.
3) Тест железа, но это крайний случай, скорее всего проблема чисто софтовая.

USE your_database_name;
show variables like "character_set_database";