Мне было интересно, нужно ли мне использовать оператор FETCH FIRST n ROWS ONLY
в DB2 или оператор LIMIT
в MySQL, если я запрашиваю уникальный идентификатор с индексом из таблицы для повышения производительности. Или sql-провайдер уже замечает, что будет максимум один результат и останавливает запрос, когда строка найдена?
Пример запроса:
БД2: SELECT * FROM myTable WHERE id = 1 FETCH FIRST 1 ROWS ONLY
MySQL: SELECT * FROM myTable WHERE id = 1 LIMIT 1
Кто-нибудь уже думал об этом?
А как же FETCH FIRST 1 ROWS ONLY
?
Я не работаю в db2, но... думаю, то же самое... этот вид лимита/флитера может применяться только к результирующему набору... а производительность зависит от извлечения результирующего набора
Если у вас уже есть уникальный индекс для id
, то обычно оптимизатор должен знать, что такой запрос не может вернуть более одной строки. Если у вас нет такого уникального индекса на id
, возможно, стоит помочь оптимизатору построить лучший план доступа.
Вы можете использовать как FETCH FIRST 1 ROWS ONLY
, так и LIMIT
в Db2, проверьте Параметры совместимости с DB2.
Если возвращается только одна строка, не имеет значения, указан ли этот синтаксис. Однако, если вы или система не уверены, это дополнительная защита. В зависимости от настроек оптимизатора (настроения, статистики или метаданных) дополнительный синтаксис может повысить производительность. Причина в том, что система базы данных знает, что должна быть возвращена только одна строка, и может оптимизировать ее для этого случая.
Если на я бы есть уникальный индекс, то это должно быть очевидно, но есть ли индекс...?
Да, в этой строке есть индекс. Я отредактировал вопрос. Итак, есть ли необходимость указывать оператор LIMIT?
Мой ответ уже включает это. Не нужно, но я бы все равно сделал это по привычке.
И когда вы включаете поддержку LIMIT в Db2, вы можете использовать этот более короткий синтаксис
В случае, если атрибут объявлен уникальным, я настоятельно рекомендую не делать этого по двум причинам:
это никоим образом не увеличивает производительность современного оптимизатора, а только увеличивает работу оптимизатора SQL, у которого есть еще одно предложение для обработки,
(самое важное) это снижает удобочитаемость оператора для сопровождающего кода, поскольку может создаться впечатление, что атрибут не уникален, что приведет к путанице в отношении запроса и базовой таблицы.
В mylsq ограничение применяется к результату выбора .. поэтому у вас нет улучшения производительности