Хз как там в MySQL, но псевдонимы таблицам я бы назначил

Тож так сначала подумал, что надо from v1_attachment сделать.
Но потом подумал, что на v1_post.user_id наверняка индекс есть.

Крайний раз MySQL в 2006-м году трогал, чего там с оптимизатором сейчас - вообще без понятия

basename, планы давай

Вообще в ms sql хорошо (в теории) было бы примерно так:

1) при наличии индекса по v1_post.user_id выбираем во времянку id и темы всех сообщения юзверя (их пока немного, это ж не Инос или Гарыныч с дедофорума с Овер 100к постов).
2) эту времянку inner join'ним на v1_attachment и v1_topic, выводим нужные поля.

Не суть, если там индекс по user_id include (post_id, topic_id), то все будет быстро (примерно к ms sql server)

Исходное (как я понял) - аттачи юзера

Вот только без подсказок

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

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

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

Условие в предложении where, а не в on соединения

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

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

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

58512

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

Та же фигня

Чего???
Почему не работает???

Ога, блеать, навтыкают хинтов, потом таблица разрастается и наступает пиздец

Там имя файла с аттачментом. Если там null - аттачмента нет.

basename, что хранится в поле v1_attachment.name?

Вполне рабочий вариант.

"Общие случаи" часто пагубно сказываться на производительности в данном конкретном случае

Планы разные.
По сути вопроса: вероятно, количество вложений подопытного несколько менее числа топиков, в которые он насрал.

По планам порядок соединения таблиц разный.
Это реальный план выполнения или предполагаемый?

Выводи время исполнения для каждого запроса