Общие правила упрощения инструкций SQL

вот несколько из работы с Oracle 8 & 9 (конечно, иногда наоборот может сделать запрос проще или быстрее):

скобки могут быть удалены, если они не используются, чтобы изменить приоритет оператора. Простой пример, когда все логические операторы в where предложение то же самое:where ((a or b) or c) эквивалентно where a or b or c.

подзапрос может часто (если не всегда) быть слился с основным запросом чтобы упростить его. По моему опыту, это часто значительно повышает производительность:

select foo.a,
       bar.a
  from foomatic  foo,
       bartastic bar
 where foo.id = bar.id and
       bar.id = (
         select ban.id
           from bantabulous ban
          where ban.bandana = 42
       )
;

эквивалентно

select foo.a,
       bar.a
  from foomatic    foo,
       bartastic   bar,
       bantabulous ban
 where foo.id = bar.id and
       bar.id = ban.id and
       ban.bandana = 42
;

используя соединения ANSI отделяет много логики" code monkey " от действительно интересных частей предложения where: предыдущий запрос эквивалентен

select foo.a,
       bar.a
  from foomatic    foo
  join bartastic   bar on bar.id = foo.id
  join bantabulous ban on ban.id = bar.id
 where ban.bandana = 42
;

если вы хотите проверить наличие строки, Не используйте count (*), вместо того, чтобы использовать rownum = 1 или поместите запрос в where exists предложение для извлечения только одной строки вместо все.

• Я полагаю, что очевидным является поиск любых курсоров, которые могут быть заменены операцией на основе SQL 'Set'.
• далее в моем списке искать любые коррелированные подзапросы, которые могут быть переписаны как некоррелированный запрос
• в длинных хранимых процедурах разбейте отдельные операторы SQL на свои собственные хранимые процедуры. Таким образом, они получат собственный кэшированный план запроса.
• ищите транзакции, у которых может быть сокращена область действия. Я регулярно нахожу операторы внутри транзакции, которые могут безопасно находиться снаружи.
• Sub-selects часто могут быть переписаны как прямые соединения (современные оптимизаторы хороши в обнаружении простых)

как упоминал @Quassnoi, оптимизатор часто делает хорошую работу. Один из способов помочь в этом-обеспечить обновление индексов и статистики и наличие подходящих индексов для рабочей нагрузки запроса.

мне нравится заменять все виды подзапросов на запрос join.

это очевидно :

SELECT  *
FROM    mytable mo
WHERE   EXISTS
        (
          SELECT  *
          FROM    othertable o
          WHERE   o.othercol = mo.col
        )

by

SELECT  mo.*
FROM    mytable mo inner join othertable o on o.othercol = mo.col

и это по оценкам :

SELECT  *
FROM    mytable mo
WHERE   NOT EXISTS
        (
          SELECT  *
          FROM    othertable o
          WHERE   o.othercol = mo.col
        )

by

SELECT  mo.*
FROM    mytable mo left outer join othertable o on o.othercol = mo.col
WHERE   o.othercol is null

это может помочь СУБД выбрать хороший план выполнения в большом запросе.

Мне нравится, что все в команде следуют набору стандартов, чтобы сделать код читаемым, ремонтопригодным, понятным, моющимся и т. д.. :)

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

здесь есть еще кое-какие мелочи Каковы некоторые из ваших самых полезных стандартов базы данных?

учитывая природу SQL, вы абсолютно должны знать о последствиях производительности любого рефакторинга. рефакторинг SQL приложений - хороший ресурс по рефакторингу с большим акцентом на производительность (см. Главу 5).

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

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

наиболее важными для упрощения предложения where, вероятно, являются законы деморгана (обратите внимание, что " · "есть" и " и " + "есть " или"):

• не (x · y) = Не x + не y
• не (x + y) = Не x · не y

это переводится в SQL на:

NOT (expr1 AND expr2) -> NOT expr1 OR NOT expr2
NOT (expr1 OR expr2) -> NOT expr1 AND NOT expr2

эти законы могут быть очень полезны при упрощении выражений where с большим количеством вложенных элементов AND и OR запасные части.

также полезно помнить, что утверждение field1 IN (value1, value2, ...) эквивалентно field1 = value1 OR field1 = value2 OR ... . Это позволяет вам отрицать IN () одним из двух способов:

NOT field1 IN (value1, value2)  -- for longer lists
NOT field1 = value1 AND NOT field1 = value2  -- for shorter lists

подзапрос также можно рассматривать таким образом. Например, это отрицается где пункт:

NOT (table1.field1 = value1 AND EXISTS (SELECT * FROM table2 WHERE table1.field1 = table2.field2))

можно переписать так:

NOT table1.field1 = value1 OR NOT EXISTS (SELECT * FROM table2 WHERE table1.field1 = table2.field2))

эти законы не говорят вам, как преобразовать SQL-запрос с помощью подзапроса в один с помощью соединения, но логика boolean может помочь вам понять типы соединений и то, что ваш запрос должен возвращать. Например, с таблицами A и B, an INNER JOIN как A AND B, a LEFT OUTER JOIN как (A AND NOT B) OR (A AND B) что упрощает к A OR (A AND B) и FULL OUTER JOIN is A OR (A AND B) OR B что упрощает для A OR B.

мой подход заключается в изучении реляционной теории в целом и реляционной алгебры в частности. Затем научитесь определять конструкции, используемые в SQL для реализации операторов из реляционной алгебры (например, универсальная квантификация a.к. a. деление) и исчисление (например, экзистенциальная квантификация). Суть в том, что SQL имеет функции, не найденные в реляционной модели, например нули, которые, вероятно, лучше всего рефакторировать. Рекомендуемое чтение:SQL и реляционная теория: Как писать Точный код SQL по C. J. Date.

в этом ключе я не убежден ,что "тот факт, что большинство Подселектов могут быть переписаны как соединение", представляет собой упрощение.

возьмите этот запрос, например:

SELECT c 
  FROM T1 
 WHERE c NOT IN ( SELECT c FROM T2 );

переписать с помощью JOIN

SELECT DISTINCT T1.c 
  FROM T1 NATURAL LEFT OUTER JOIN T2 
 WHERE T2.c IS NULL;

соединение более многословно!

альтернативно, признать, что конструкция реализует антисоединение на проекции c например, псевдо algrbra

T1 { c } antijoin T2 { c }

упрощение использование реляционных операторов:

SELECT c FROM T1 EXCEPT SELECT c FROM T2;