Добрий, поганий або байдужий: ДЕ 1 = 1

З огляду на це запитання в reddit, я очистив запит, щоб вказати, де проблема в запиті. Я спочатку використовую кому і WHERE 1=1щоб полегшити модифікацію запитів, тому мої запити, як правило, закінчуються так:

SELECT 
     C.CompanyName
    ,O.ShippedDate
    ,OD.UnitPrice
    ,P.ProductName
FROM 
               Customers       as C
    INNER JOIN Orders          as O  ON C.CustomerID = O.CustomerID
    INNER JOIN [Order Details] as OD ON O.OrderID    = OD.OrderID
    INNER JOIN Products        as P  ON P.ProductID  = OD.ProductID
Where 1=1
--  AND O.ShippedDate Between '4/1/2008' And '4/30/2008'
    And P.productname = 'TOFU'
Order By C.CompanyName

Хтось в основному сказав, що 1 = 1, як правило, ледачий і поганий у виконанні .

Зважаючи на те, що я не хочу "передчасно оптимізувати" - я хочу дотримуватися належної практики. Раніше я розглядав плани запитів, але, як правило, лише для того, щоб дізнатися, які індекси я можу додати (або відкоригувати), щоб мої запити працювали швидше.

Тоді питання справді ... чи Where 1=1спричиняє погані речі? А якщо так, то як я можу це сказати?

Незначна редакція: Я також завжди "припускав", що 1=1було б оптимізовано, або, в гіршому випадку, мізерно. Ніколи не завадить ставити під сумнів мантру, наприклад "Гото - це зло" чи "Передчасна оптимізація ..." чи інші припущені факти. Не був впевнений, чи 1=1 ANDреально це вплине на плани запитів чи ні. А як щодо підзапитів? CTE? Процедури?

Я не хочу оптимізувати, якщо це не потрібно ... але якщо я роблю щось, що насправді є "поганим", я б хотів мінімізувати ефекти або змінити, де це можливо.

Сервер SQL аналізатороптимізатор має функцію під назвою "Постійне складання", яка виключає тавтологічні вирази з запиту.
Якщо ви подивитесь на план виконання, ніде в предикатах ви не побачите, що цей вираз з’явиться. Це означає, що постійне складання виконується так чи інакше під час компіляції з цієї та інших причин, і це не впливає на ефективність запитів.

Додаткову інформацію див. У розділі Оцінка постійного складання та вираження під час оцінки кардинальності .

Додавання надлишкового предиката може змінити SQL Server.

На планах виконання нижче зауважте, що @1у першому плані порівняно з буквальним 'foo'у другому плані.

Це вказує на те, що SQL Server вважав першим запитом просту параметризацію для сприяння повторному використанню плану виконання - однак порівняння двох констант запобігає цьому у другому випадку.

Перелік умов, які перешкоджають простій параметризації (раніше відомі як автоматична параметризація), можна знайти в Додатку А до програми кешування технічних документів Microsoft:

• Проблеми пакетної компіляції, перекомпіляції та кешування плану в SQL Server 2005
• Планування кешування в SQL Server 2008
• Планування кешування та рекомпіляції в SQL Server 2012

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

У будь-яких сучасних RDBMS (включаючи Oracle, Microsoft SQL Server та PostgreSQL - я впевнений у цьому) це не вплине на продуктивність.

Як хтось зазначив, це вплине лише на етап планування запитів. Отже різниця буде помітна лише тоді, коли ви запустите тисячі ітерацій спрощеного запиту, який не повертає жодних даних, як цей:

SELECT 1 FROM empty_table; -- run this 10 000 times.

SELECT 1 FROM empty_table WHERE 1=1; -- run this 10 000 times and compare.

Для мене на PostgreSQL 9.0 це видно лише 10000 ітерацій:

filip@srv:~$ pgquerybench.pl -h /var/run/postgresql/ -q "select 1 from never where 1=1" -q "select 1 from never" -i 10000
Iterations: 10000
Query:   select 1 from never where 1=1
Total:   2.952 s
Average: 0.295 ms
Query:   select 1 from never
Total:   2.850 s
Average: 0.285 ms

Це може бути "проблемою" для Oracle, коли ви використовуєте параметр бази даних cursor_sharing. Якщо для цього встановлено значення "примусити", воно змінить усі оператори SQL. Усі "константи" в запитах будуть замінені змінними прив'язки (наприклад, 1 =>: SYS_0).

Цей варіант був введений для боротьби з деякими ледачими розробниками. З іншого боку, це також може зашкодити іншим ледачим розробникам. Але ризик не надто високий. Починаючи з 11 г, він має функцію прививки змінного вигляду.