Теоретег детектед. Таблица постов самая здоровая (овердохуя записей относительно остальных таблиц), в случае иннер джоина условия соединения равносильны условиям в предложении where и оптимизатор может снача на сотни тысяч записей в таблице постов начать джоинить другие таблицы, что может потребовать выделения значительного объема ОЗУ и сброса результата в tempdb, что не есть продуктивно.
У Бази в первоначальном запросе на таблицу постов накладывается ограничение по юзер_ид, что в случае индекса по юзер_ид инклуде (пост_ид, топик_ид) сведётся к поиску по индексу для выделения постов автора и джоину по относительно небольшому числу постов конкретного юзера. Правда у него тогда в where мешает условие на is not null для вложения.

З.ы. нет планов - нет аналитики.
З.з.ы. вышеописанное применительно к ms sql, чего там с оптимизатором mysql - я хз

У Бази условие в where на is not null для поля таблицы из left join

Йожег попутал, у тебя is not null в where, а не в on

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

З.Ы. Нужны планы.
З.З.Ы. планы имеют тенденцию становиться неактуальными с увеличением числа записей.

58512

С точки зрения поставленной задачи (выбрать все аттачменты юзера) запрос в стартовом посте корректен