Да, конечно, не досмотрел ошибку, которую сам обычно не допускаю - она была и в изначальном запросе. Условие в where при соединении таблицы через left join нивелирует этот самый left, потому что значение в случае отсутсвия ключа будет null. По этой причине надо либо вставлять этот фильтр внутри подзапроса, как Вы и предложили, либо прописывать в условии соединения
sc.sale_id = scm.sale_id and scm.type = "image". Исправил запрос.
Anubis: Понял Вашу проблему. Тогда главное, чтобы поле сортировки было индексировано, а еще лучше - входило в составной индекс, используемый при фильтрации (запросы не пользовательские, а зафиксированы в движке сайта, поэтому может иметь смысл). Подробнее механика работы описана тут. В этом случае обращение к данным самой таблицы буде только в самом конце, при отображении результата.
Третья нормальная форма
Пока таблица соответствует данным требованиям, разбивать ее смысла не имеет. Скорость работы индекса не зависит от наличия других полей в таблице.
Разве что будет возникать необходимость архивации данных. Но и тогда бы я думал в сторону партиционирования таблицы, а не выделения комментариев в отдельную.
Повода для дробления таблицы с комментариями здесь не вижу, только дополнительный индекс по второй таблице появляется, который будет идентичен первому (в двух таблицах мы имеем id поста + id комментария)
Оффтоп - на досуге можете почитать use-the-index-luke.com
Помогает структурировать то, что Вы уже знали и уверен, почерпнете нового для себя.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
