Помогите составить SQL-запрос для вывода дерева комментариев.

Самый простой и вместе с тем гениальный способ построения дерева, это не использовать никакие id, parent_id, не использовать

Ну-ну, далеко пойдешь. Если бы ты строил дерево как все нормальные люди с id и parent_id, то мог бы потом по-царски написать рекурсивный запрос, и тогда у тебя что угодно влезло бы в этот один запрос. Например так:

with threads_recursive (comment_id, comment_data) as (
  select i.comment_id, 
         i.comment_data 
  from comments i 
  where i.comment_id = 1
  union all
  select c.comment_id, 
         c.comment_data 
  from threads_recursive p 
  inner join comments c on c.parent_id = p.comment_id
) select * from threads_recursive;

Но ты закладываешь весьма странное решение в свою конструкцию, и поэтому тебе предстоит всю дорогу трахаться с substr(instr(substr(instr())))). Причем, не факт, что у тебя всегда получится выражать то, что там тебе понадобится.

Не проверял

select * from forum f 
left join (select substring_index(thread_path, '.', 1) as root,
             max(comment_id) as max 
             from forum group by root
          ) o on substring_index(f.thread_path, '.', 1)=o.root 
order by o.max desc, f.thread_path

Самый верный, ИМХО, способ

Есть еще nested set

Добавь столбец root_comment_id и делай order by root_comment_id desc, thread_path.

Но ты закладываешь весьма странное решение в свою конструкцию

Это типовое решение. Самое быстрое, когда требуется выборка по конкретному пути. С parent_id придётся крутить циклы.

Другое дело, что обычно в таком случае не экономят и хранят как «собранный» путь, так и parent_id :)

хранят как «собранный» путь, так и parent_id

Разумная тема, кстати. Spoofing, ты слышишь?

cамое быстрое, когда требуется выборка по конкретному пути

Рекурсивный SQL все равно будет быстрее и удобнее в большинстве задач. Путь собрать - тоже невелика проблема:

with threads_recursive (comment_id, comment_data, comment_path) as (
  select i.comment_id, 
         i.comment_data 
         i.comment_id as comment_path
  from comments i 
  where i.comment_id = 1
  union all
  select c.comment_id, 
         c.comment_data 
         p.comment_path || c.comment_id as comment_path
  from threads_recursive p 
  inner join comments c on c.parent_id = p.comment_id
) select * from threads_recursive;

А вот если тебе наоборот надо будет достать айдишники из готового пути в VARCHAR, то придется поизвращаться.

А вообще, если ты уж пишешь веб-приложение на пыхе, то надо пользоваться ORM и не морочить себе голову.

Иначе говоря, при наличии ОРМа сиквель можно не учить? Последнее время я примерно так и представляю назначение этой надстройки — дать возможность работы с базой для неосиляторов, которая тщательно маскируется тезисом про независимость от СУБД. На практике при этом СУБД почти в 100 процентах случает никогда не меняется.

Надеюсь я не прав.

По теме — забить и строить дерево своим пыхом или шаблонизатором на фронтэнде.

Нафига тебе полный thread_path, храни root_path, это гораздо юзабельнее. Если без полного пути никак - храни оба.

Иначе говоря, при наличии ОРМа сиквель можно не учить?

Ну, не хочешь учить - не учи, будь лохом. Только не приписывай эти слова мне, я такого не говорил.

Надеюсь я не прав

Ты не прав. ORM призван закрыть разрыв между реляционной и объектной парадигмами путем представления реляционных сущностей в виде нативных объектов. Он не обязательно будет db-agnostic, и это не является его основной целью.

Самый простой и вместе с тем гениальный способ построения дерева

Ну-ну. Кнута почитай сначала, прежде чем писать «гениальный».