|
Задавайте вопросы, мы ответим
Вы не зашли.
Здравствуйте, извиняюсь если такая тема уже была. Изучаю mysql, допустим есть такие таблицы:
Неактивен
1. укажите в явном виде первичные ключи по id
2. про составные индексы см FAQ №5
если может быть условие по одному из полей, то
(brand_id, category_id) и отдельно (category_id)
или
(category_id, brand_id) + (brand_id)
или, например, при небольшом количестве возможных значений brand_id при отсутствии условия на это поле можно добавить условие в запрос, перечислив все поля - brand_id IN (1,2,3,4,5)
p.s. limit без order by - игра в рулетку
Неактивен
vasya написал:
1. укажите в явном виде первичные ключи по id
2. про составные индексы см FAQ №5
если может быть условие по одному из полей, то
(brand_id, category_id) и отдельно (category_id)
или
(category_id, brand_id) + (brand_id)
или, например, при небольшом количестве возможных значений brand_id при отсутствии условия на это поле можно добавить условие в запрос, перечислив все поля - brand_id IN (1,2,3,4,5)
p.s. limit без order by - игра в рулетку
Здравствуйте, спасибо за ответ. Да как раз меня интересует именно тот случай, когда таких полей много и в условии для выборки какие-то поля могут отсутствовать.
Неактивен
vasya написал:
p.s. limit без order by - игра в рулетку
Насчет этого можно подробнее пожалуйста? Т.е всегда где присутствует limit, нужно обязательно делать сортировку?
Отредактированно webJunior (05.04.2017 11:57:15)
Неактивен
да, иначе у вас нет гарантии того какие результаты вернет запрос
Неактивен
vasya написал:
да, иначе у вас нет гарантии того какие результаты вернет запрос
В как быть с такими запросами, когда сортировка не нужна?
Например:
SELECT * FROM t WHERE t.id=:id LIMIT 1
Неактивен
если id уникальное поле, то зачем здесь limit?
если одному значению id соответствует несколько записей, то какую из них вы хотите получить? и устроит ли вас ситуация, когда выполняя один и тот же запрос вы получаете разные данные? если да, то конечно можно и не использовать сортировку
Неактивен
vasya написал:
если id уникальное поле, то зачем здесь limit?
если одному значению id соответствует несколько записей, то какую из них вы хотите получить? и устроит ли вас ситуация, когда выполняя один и тот же запрос вы получаете разные данные? если да, то конечно можно и не использовать сортировку
Ok.
Я просто немного запутался, под разными данными что имеется ввиду? Например если есть условие where, можно получить данные не попадающие в условие или то что данные придут в разной последовательности?
Неактивен
пусть условию where соответствуют 3 записи
вы пишите limit 1 без сортировки
какая из 3 записей, соответствующих условию where будет возвращена?
и всегда ли при повторном выполнении запроса будет возвращена именно та запись, которая была получена первоначально, или в будущем можно получить другую из те 3ёх, что соответствуют условию where?
Неактивен
vasya написал:
пусть условию where соответствуют 3 записи
вы пишите limit 1 без сортировки
какая из 3 записей, соответствующих условию where будет возвращена?
и всегда ли при повторном выполнении запроса будет возвращена именно та запись, которая была получена первоначально, или в будущем можно получить другую из те 3ёх, что соответствуют условию where?
Про Limit 1 понял, спасибо.
Вот например есть такой запрос, с постраничной навигацией где не важно в какой последовательности получу данные:
SELECT * FROM messages WHERE user_id=:user_id LIMIT 0,10
Я получу данные попадающие в условие, но разной последовательности? Т.е в таком случае если последовательность не важна, ORDER BY могу не указывать?
Отредактированно webJunior (05.04.2017 13:36:00)
Неактивен
а потом пользователь перейдет на следующую страницу, т.е. LIMIT 10, 20
и где гарантия, что среди новых случайных 10 значений не будет тех, которые были показаны на прошлой странице?
и с т.з. оптимизации order by + limit позволяют иногда оптимизировать выполнение запроса
Неактивен
vasya написал:
а потом пользователь перейдет на следующую страницу, т.е. LIMIT 10, 20
и где гарантия, что среди новых случайных 10 значений не будет тех, которые были показаны на прошлой странице?
и с т.з. оптимизации order by + limit позволяют иногда оптимизировать выполнение запроса
Ясно, спасибо!
Неактивен
