Станислав Макаров

1) не могу понять зачем вам id и size в таблице post_likes. Для регистрации факта и времени лайка достаточно этого: (idPost, idUser, date) с ключом (idPost, idUser).
2) почему ORDER BY id а не по дате?
3) сделайте нормальные нужные вам индексы, включающие поля по которым вы фильтруете и сортируете (с указанием порядка сортировки).

Под большой нагрузкой с такой задачей лучше графовую базу пробовать (когда много связей, как у вас с подписчиками).

Вам уже посоветовали использовать json, я попробую дать более общую рекомендацию. У вас стандартная для вашей предметной области проблема - отсутствие единой схемы данных, у вас имеющихся. Очень редко в работающем приложении кто-либо меняет схему "на ходу" - т.е. в 99% случаев схема (по кр. мере логическая) проектируется вместе с приложением. Новая версия приложения - новая схема (при необходимости, конечно). Таким образом, ваша задача диктует вам необходимость работать с ЧАСТЬЮ ваших данных без использования схемы. Согласитесь, это не очень гибко - заводить новую таблицу под каждый вид товара, коих огромное количество может быть. Самое главное, новые товары приходят каждый день, и каждый день добавлять таблицы - с ума сойдешь. И совершенно непонятно, как при этом разрабатывать SQL-запросы на выборку, учитывая все новые и новые таблицы.
Т.о., часть данных вам лучше хранить иначе, а именно атрибуты ваших товаров. Тут подхода два: это либо полуструктурированные данные (semistructured), т.е. XML или JSON, либо EAV модель. Последняя является классическим выходом из ситуации при использовании реляционных баз данных, однако т.к. она по определению идет в разрез с реляционной структурой данных - это все по сути большой костыль. Сегодня все чаще рекомендуют первый вариант, т.к. во-первых многие современные РСУБД поддерживают JSON или XML типы данных, причем даже с возможностями валидации и выборки (а если и нет - BLOB всегда поможет), а во-вторых под каталог товаров можно использовать любую документную базу данных, которая кстати еще и лучше подойдет по специфике нагрузки на каталог (очень много чтения и мало записи, целостность не особо нужна - шардинг будет без особых проблем).
Итого:
1) понимаете, почему не все данные не всегда получается уложить в фиксированную схему
2) выбираете себе подходящее решение из перечисленных, помня, что можно (и нужно!) часть данных хранить в нормализованном виде, а часть - не получится.
3) поиск и выборка по ненормализованным данным рассматривается как отдельная задача
P.S. вот как раз таки в корзину достаточно класть ID товара и его количество, что отлично уложится в реляционную схему. А для этого таблица товаров одна должна быть.

Может нужно все-таки подходящий индекс подобрать и для третьего поля? Как вам повторный селект-то поможет, если все равно надо фильтровать по третьему полю? Что у вас за тип у третьего поля и какой у вас фильтр на него?

То, что у вас есть - это EAV-моделька. То, что вы хотите с ней сделать - превратить в обычное отношение - вполне можно назвать Pivot.
Вот тут SO подоспел с советами, как раз по вашей части, включая MySQL:
stackoverflow.com/questions/8764290/what-is-best-p...
stackoverflow.com/questions/649802/how-to-pivot-a-...

SQL писать не буду, проверять долго, предложу просто идею: нужно получить вычисляемую дату+время, с помощью которой можно выстроить на одной временной шкале по порядку как ежедневые дела, так и события. По сути, ежедневные дела это ежедневные события - т.е. события, у которых дата = сегодняшяя_дата+время_ежедневного_дела. Для дел, у которых время начала не указано, ставить дефолтовое (например, полдень). Итого:
1) оставляем union
2) добавляем в подзапрос from daily вычисляемое значение, которое собирается из текущей даты и значения поля time, задаем ему имя, напр. occurence_time;
3) дату+время ивента в подзапросе from events также вытаскиваем as occurence_time;
4) теперь вроде ничего не мешает отсортировать по полю occurence_time слитые в одно множество события.