Igo, спасибо, но не работает.
получается он собирает все в одну строчку, все alert, с разных поездов, то есть получается 1 поезд, примерно такой:

2 | 11:00 | 10:1,12:3,19:1,1:3,5:3,29:1

и имелось ввиду

Igo написал(а):

carriage.train_id = train.id

вместо

Igo написал(а):

carriage.train_id = 'определенный номер'

.

Igo написал(а):

обращай тоже внимание на оформление- это и тебе поможет самому не запутаться, и другим кто будет смотерть твой код.

знаю, я старался)) но видимо не получилось))

Исправлено Fire Stream (25.05.12 21:18)

точно - сорри, про группировку забыл - ну ты сам разобрался, молодца.

Fire Stream написал(а):

осталось сделать чтобы показывались поезда у которых нет ни одного вагона с alert > 0.

тогда вместо join, используй left join

Fire Stream написал(а):

Теперь работает меньше секунды и как надо.

OMG, сколько же там строк в таблицах?
мож это, индексов еще добавить?

если записей много, и еще нет индексов - то left join будет работать очень медленно - потому в таких запросах надо пытаться оперировать минимальным количеством строк

например как у тебя через временные таблицы, или вот так - через вложенный запрос

SELECT
  train.id,
  train.time_in,
  IFNULL(carriage.alert_level > 0,
         GROUP_CONCAT( CONCAT(carriage.number, ':', carriage.alert_level) SEPARATOR ','))

FROM
  train
  LEFT JOIN carriage
         ON carriage.train_id = train.id
         
where
  train.id in (
    select
      train.id
      
    from
      train
      
    order by
      train.time_in desc
      
    limit 10
  )

GROUP BY
  carriage.train_id

ORDER BY
  train.time_in DESC

ну или в некоторых случаях - очень внимательно надо смотреть, и по возможности не использовать такой подход - но в некоторых случаях так бывает производительнее всего ( ЭТО НЕКРАСИВО И НЕКРУТО ) - выполнить отдельно два запроса - сначала по сути начитать 10 id - то что у меня во вложенном запросе - и подставить это в виде фильтра в основной запрос.

$up написал(а):

Для оптимизации сложных запросов в MS SQL нужно всегда смотреть Execution plan, там всё наглядно расписано. Это, помогает увидеть когда используются индексы а когда нет.

Это для любой базы верно:))

нафиг временную таблицу, делай с вложенным запросом и объединяй с его результатом
обязательно нужны индексы по полям, по которым производится сортировка (order by) и объединение таблиц, остальные - по результатам осмотра плана выполнения запроса

Igo написал(а):

sav написал(а):

Обычно, выполнение с подзапросами. медленее, чем когда joinишь. Но чтобы не быть голословным, надо получить execution план и сравнить cost.

однозначно в этом случае будет быстрее подзапрос.

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

Оч. сложно спорить, мы с вами друг друга не знаем. Для меня самый надежный источник в данный момент - stackoverflow.com

inner join vs. subqueries:
http://stackoverflow.com/questions/1412 … s-vs-joins

left join vs. subqueries:
http://stackoverflow.com/questions/1788 … inner-join

объясняется тем, что в случае subquery вызывается для каждой строчки, в случае inner/left join - как bulk операция.
Если вы укажете более серьезный источник, я ради интереса выложу для обсуждения в предыдущие топики на stackoveflow.com.

Естественно на английском.

sav написал(а):

inner join vs. subqueries:
http://stackoverflow.com/questions/1412 … s-vs-joins

Здесь описывается ситуация, когда подзапрос используется в конструкции select - т.е. формируется определенная выборка, и потом уже к КАЖДОЙ строке выполняется свой подзапрос - тут бесспортно будет рулить не подзапрос а join по производительности, если он позволит выкрутиться из ситуации. другое дело что не всегда можно подзапрос заменить на join - пример - например мы выводим список рубрик каталога, и нам надо вывести в этой же строчке название первого вложенного в эту рубрику товара - join без подзапроса в данном случае я хз как пострить.

sav написал(а):

left join vs. subqueries:
http://stackoverflow.com/questions/1788 … inner-join

Тут же написано

A "correlated subquery" (i.e., one in which the where condition depends on values obtained from the rows of the containing query) will execute once for each row. A non-correlated subquery (one in which the where condition is independent of the containing query) will execute once at the beginning. The SQL engine makes this distinction automatically.

т.е. НЕ ВСЕГДА подзапрос выполняется для каждой строки. Для каждой строки он выполнятся если эти запросы "коррелируют" - т.е. подзапрос оперирует данными "внешнего" относительно него запроса. А в нашем же случае такого нет, потому подзапрос выполнится всего 1 раз, а не для каждй строки.
http://msdn.microsoft.com/ru-ru/library … 05%29.aspx

Если я где то не прав - поправьте меня.