Отказ от ответственности: все нижеприведенное является анекдотическим и основано непосредственно на моем личном опыте. Любой, кто считает нужным провести более строгий эмпирический анализ, может провести его и проголосовать против, если я. Я также знаю, что SQL - это декларативный язык, и вам не нужно учитывать, КАК ваш код обрабатывается, когда вы его пишете, но, поскольку я ценю свое время, я это делаю.
Существует бесконечное количество логически эквивалентных утверждений, но я рассмотрю три (иш).
Случай 1: два сравнения в стандартном порядке (фиксированный порядок оценки)
A> = MinBound И A <= MaxBound
Случай 2: Синтаксический сахар (порядок оценки не выбран автором)
МЕЖДУ MinBound И MaxBound
Случай 3: два сравнения в образованном порядке (порядок оценки выбран во время написания)
A> = MinBound И A <= MaxBound
Или
A <= MaxBound AND A> = MinBound
По моему опыту, случаи 1 и 2 не имеют каких-либо последовательных или заметных различий в производительности, поскольку они игнорируют набор данных.
Однако вариант 3 может значительно сократить время выполнения. В частности, если вы работаете с большим набором данных и у вас есть некоторые эвристические знания о том, будет ли A больше, чем MaxBound или меньше, чем MinBound, вы можете заметно улучшить время выполнения, используя случай 3 и упорядочивая сравнения соответственно.
Один из вариантов использования, который у меня есть, - это запрос большого набора исторических данных с неиндексированными датами для записей в пределах определенного интервала. При написании запроса я буду иметь представление о том, существует ли больше данных ДО указанного интервала или ПОСЛЕ указанного интервала, и могу соответственно упорядочить свои сравнения. У меня время выполнения сократилось наполовину в зависимости от размера набора данных, сложности запроса и количества записей, отфильтрованных при первом сравнении.