Зачем кому-то использовать WHERE 1 = 1 AND <conditions> в предложении SQL?

Если список условий неизвестен во время компиляции и вместо этого создается во время выполнения, вам не нужно беспокоиться о том, есть ли у вас одно или несколько условий. Вы можете сгенерировать их все, например:

and <condition>

и соедините их все вместе. С 1=1 вначале, у первоначального and есть что связать.

Я никогда не видел, чтобы это использовалось для какой-либо защиты от инъекций, как вы говорите, похоже, что это не сильно поможет. Я видел, что имеют используется для удобства реализации. Механизм запросов SQL в конечном итоге проигнорирует 1=1, поэтому это не должно повлиять на производительность.

Похоже на ленивый способ всегда знать, что ваше предложение WHERE уже определено и позволяет вам продолжать добавлять условия, не проверяя, является ли оно первым.

Выражение 1 = 1 обычно используется в сгенерированном коде sql. Это выражение может упростить создание кода sql, уменьшив количество условных операторов.

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

Вы можете объединить условия, используя строку «И». Затем вместо подсчета количества условий, которые вы передаете, вы помещаете «WHERE 1 = 1» в конец стандартного оператора SQL и добавляете конкатенированные условия.

По сути, это избавляет вас от необходимости выполнять проверку условий и затем добавлять перед ними строку «WHERE».

Просто добавив пример кода к ответу Грега:

dim sqlstmt as new StringBuilder
sqlstmt.add("SELECT * FROM Products")
sqlstmt.add(" WHERE 1=1") 

''// From now on you don't have to worry if you must 
''// append AND or WHERE because you know the WHERE is there
If ProductCategoryID <> 0 then
  sqlstmt.AppendFormat(" AND ProductCategoryID = {0}", trim(ProductCategoryID))
end if
If MinimunPrice > 0 then
  sqlstmt.AppendFormat(" AND Price >= {0}", trim(MinimunPrice))
end if

На самом деле, я видел такие вещи, используемые в отчетах BIRT. Запрос, переданный среде выполнения BIRT, имеет форму:

select a,b,c from t where a = ?

и '?' заменяется во время выполнения фактическим значением параметра, выбранным из раскрывающегося списка. Варианты выбора в раскрывающемся списке представлены:

select distinct a from t
union all
select '*' from sysibm.sysdummy1

так что вы получите все возможные значения плюс "*". Если пользователь выбирает «*» из раскрывающегося списка (это означает, что должны быть выбраны все значения a), запрос должен быть изменен (с помощью Javascript) перед запуском.

Поскольку "?" является позиционным параметром и ДОЛЖЕН оставаться там для работы других вещей, Javascript изменяет запрос следующим образом:

select a,b,c from t where ((a = ?) or (1==1))

Это в основном устраняет эффект предложения where, оставляя при этом позиционный параметр на месте.

Я также видел случай AND, используемый ленивыми кодировщиками при динамическом создании SQL-запроса.

Допустим, вам нужно динамически создать запрос, который начинается с select * from t и проверяет:

• зовут Боб; и
• зарплата> 20000 долларов

некоторые люди добавляли бы первые с помощью WHERE, а последующие с помощью AND, таким образом:

select * from t where name = 'Bob' and salary > 20000

Ленивые программисты (и это не обязательно признак плохой) не будут различать добавленные условия, они начнут с select * from t where 1=1 и просто добавят после этого предложения AND.

select * from t where 1=1 and name = 'Bob' and salary > 20000

Впервые я столкнулся с этим с ADO и классическим asp, и получил ответ: представление. если ты сделаешь прямой

Select * from tablename

и передайте это как команду / текст sql, вы получите заметное увеличение производительности с

Where 1=1

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

где 1 = 0, это делается для проверки, существует ли таблица. Не знаю, почему используется 1 = 1.

Хотя я вижу, что 1 = 1 было бы полезно для сгенерированного SQL, метод, который я использую в PHP, заключается в создании массива предложений, а затем

implode (" AND ", $clauses);

таким образом избегая проблемы наличия начального или конечного AND. Очевидно, это полезно только в том случае, если вы знаете, что у вас будет хотя бы одно предложение!

Вот близкий пример: использование оператора SQL MERGE для обновления целевой таблицы с использованием всех значений из исходной таблицы, где нет общего атрибута, к которому можно было бы присоединиться, например.

MERGE INTO Circles
   USING 
      (
        SELECT pi
         FROM Constants
      ) AS SourceTable
   ON 1 = 1
WHEN MATCHED THEN 
  UPDATE
     SET circumference = 2 * SourceTable.pi * radius;

Использование предиката наподобие 1=1 - это обычная подсказка, которая иногда используется, чтобы заставить план доступа использовать или не использовать сканирование индекса. Причина, по которой это используется, заключается в том, что вы используете многослойный объединенный запрос со многими предикатами в предложении where, где иногда даже использование всех индексов заставляет план доступа читать каждую таблицу - полное сканирование таблицы. Это лишь один из многих советов, используемых администраторами баз данных, чтобы обмануть базу данных и заставить ее использовать более эффективный путь. Только не бросайте ни одного; вам нужна база данных для анализа запроса, поскольку она не всегда работает.

Косвенно релевантно: когда используется 1 = 2:

CREATE TABLE New_table_name 
as 
select * 
FROM Old_table_name 
WHERE 1 = 2;

это создаст новую таблицу с той же схемой, что и старая таблица. (Очень удобно, если вы хотите загрузить данные для сравнения)

Обычно я делаю это, когда создаю динамический SQL для отчета, в котором есть много раскрывающихся значений, которые может выбрать пользователь. Поскольку пользователь может или не может выбирать значения из каждого раскрывающегося списка, нам сложно определить, какое условие было первым предложением where. Итак, мы дополняем запрос where 1=1 в конце и добавляем все предложения where после этого.

Что-то типа

select column1, column2 from my table where 1=1 {name} {age};

Затем мы создадим предложение where, подобное этому, и передадим его в качестве значения параметра.

string name_whereClause= ddlName.SelectedIndex > 0 ? "AND name ='"+ ddlName.SelectedValue+ "'" : "";

Поскольку выбор предложения where нам неизвестен во время выполнения, это очень помогает нам в определении того, следует ли включать 'AND' or 'WHERE'..

Why would someone use WHERE 1=1 AND <proper conditions>

У меня домашние фреймворки видимый делают такие вещи (краснеть), поскольку это позволяет применять методы ленивого синтаксического анализа как к ключевым словам WHERE, так и к AND Sql.

Например (здесь я использую C# в качестве примера), рассмотрите условный синтаксический анализ следующих предикатов в Sql-запросе string builder:

var sqlQuery = "SELECT * FROM FOOS WHERE 1 = 1"
if (shouldFilterForBars)
{
    sqlQuery = sqlQuery + " AND Bars > 3";
}
if (shouldFilterForBaz)
{
    sqlQuery = sqlQuery + " AND Baz < 12";
}

«Преимущество» WHERE 1 = 1 означает, что никакого специального кода не требуется:

• Для И - должен ли применяться ноль, один или оба предиката (Bars и Baz), которые будут определять, требуется ли первый AND. Поскольку у нас уже есть хотя бы один предикат с 1 = 1, это означает, что AND всегда в порядке.
• Без предикатов вообще - в случае, когда есть предикаты НУЛЯ, то WHERE должен быть отброшен. Но опять же, мы можем полениться, потому что мы снова гарантируем хотя бы один предикат.

Это, очевидно, плохая идея, и мы бы рекомендовали использовать установленную структуру доступа к данным или ORM для такого анализа необязательных и условных предикатов.

Если вы пришли сюда в поисках WHERE 1, обратите внимание, что WHERE 1 и WHERE 1=1 идентичны. WHERE 1 используется редко, потому что некоторые системы баз данных отвергают его, считая, что WHERE 1 на самом деле не является логическим.

Я нашел полезный этот шаблон, когда я тестирую или дважды проверяю что-то в базе данных, поэтому я могу очень быстро прокомментировать другие условия:

CREATE VIEW vTest AS
SELECT FROM Table WHERE 1=1 
AND Table.Field=Value
AND Table.IsValid=true

превращается в:

CREATE VIEW vTest AS
SELECT FROM Table WHERE 1=1 
--AND Table.Field=Value
--AND Table.IsValid=true

Это полезно в случае, когда вам нужно использовать динамический запрос, в котором где предложение вам необходимо добавить некоторые параметры фильтра. Например, если вы включите параметры, 0 для статуса неактивен, 1 для активного. Исходя из параметров, есть только два доступных варианта (0 и 1), но если вы хотите отобразить все записи, удобно включить его, где close 1 = 1. См. Образец ниже:

Declare @SearchValue    varchar(8) 
Declare @SQLQuery varchar(max) = '
Select [FirstName]
    ,[LastName]
    ,[MiddleName]
    ,[BirthDate]
,Case
    when [Status] = 0 then ''Inactive''
    when [Status] = 1 then ''Active''
end as [Status]'

Declare @SearchOption nvarchar(100)
If (@SearchValue = 'Active')
Begin
    Set @SearchOption = ' Where a.[Status] = 1'
End

If (@SearchValue = 'Inactive')
Begin
    Set @SearchOption = ' Where a.[Status] = 0'
End

If (@SearchValue = 'All')
Begin
    Set @SearchOption = ' Where 1=1'
End

Set @SQLQuery = @SQLQuery + @SearchOption

Exec(@SQLQuery);

Изучив все ответы, я решил провести эксперимент, например

SELECT
*
FROM MyTable

WHERE 1=1

Затем я проверил другие числа

WHERE 2=2
WHERE 10=10
WHERE 99=99

т. д. После выполнения всех проверок город выполнения запроса останется прежним. даже без предложения where. Я не фанат синтаксиса

Вот пример использования ... однако я не слишком озабочен техническими особенностями того, почему я должен или не использовать 1 = 1. Я пишу функцию, используя pyodbc для извлечения некоторых данных из SQL Server. Я искал способ заставить заполнитель после ключевого слова where в моем коде. Это действительно было отличное предложение:

if _where == '': _where = '1=1'
...
...
...
cur.execute(f'select {predicate} from {table_name} where {_where}')

Причина в том, что я не смог реализовать ключевое слово 'where' вместе внутри переменной предложения _where. Итак, я думаю, что в качестве наполнителя можно использовать любое фиктивное условие, которое оценивается как истинное.

Сделав "where 1 = 1" стандартом для всех ваших запросов, также тривиально упростить проверку sql, заменив его на where 1 = 0, что удобно, когда у вас есть пакеты команд / файлов.

Также упрощает поиск конца раздела from / join любого запроса. Даже запросы с подзапросами при правильном отступе.