W Cat - SQL за 24 часа Страница 40

• Необходимость использования индексов

• Как избежать использования OR и HAVING

• Как избежать долгих операций сортировки

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

Оптимизация оператора SQL состоит, главным образом, в выборе правильной формы выражений ключевых слов FROM и WHERE. Именно в зависимости от формы этих двух выражений сервер базы данных решает, как и в каком порядке следует выполнить запрос. К данному моменту вы уже ознакомились с основными принципами построения выражений ключевых слов FROM и WHERE. Теперь пришло время заняться изучением приемов оптимизации этих выражений для ускорения работы операторов в целом и, как следствие, максимального удовлетворения запросов пользователя.

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

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

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

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

Необходимость форматирования операторов SQL кажется вполне естественной, точно также вполне естественным кажется и упоминание о форматировании здесь. Есть несколько моментов, которые не очень опытные в использовании SQL программисты обычно склонны не принимать во внимание. В следующих разделах мы обсудим перечисленные ниже вопросы - некоторые из них вытекают из обычных соображений здравого смысла, но некоторые не так очевидны.

• Форматирование операторов SQL для лучшего восприятия

• Порядок перечисления таблиц в выражении ключевого слова FROM

• Размещение наиболее ограничительных условий в выражении ключевого слова WHERE

• Размещение условий связывания в выражении ключевого слова WHERE

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

Форматировать операторы SQL для лучшего восприятия вполне естественно, но, тем не менее, многие программисты не очень заботятся о виде создаваемых ими операторов. И хотя от внешнего вида оператора его скорость работы не зависит (база данных на красоту оператора внимания не обращает), правильное форматирование является первым шагом на пути оптимизации оператора SQL. При рассмотрении оператора SQL с точки зрения ускорения его работы прежде всего удобно сделать оператор максимально простым для чтения. Но как определить, является оператор удобным для чтения или нет?

Вот некоторые правила, следуя которым можно улучшить восприятие оператора.

• Каждое ключевое слово со своим выражением следует начинать с новой строки. Например, выражение с ключевым словом FROM не следует размещать в той же строке, что и выражение с ключевым словом SELECT. Точно также выражение с ключевым словом WHERE не следует размещать в той же строке, что и выражение с ключевым словом FROM и т. д.

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

• Отступы должны быть согласованными.

• При использовании в операторе нескольких таблиц используйте для таблиц псевдонимы. Использование полных имен таблиц быстро засоряет оператор и делает его трудным для понимания.

• Не увлекайтесь использованием комментариев в операторе (конечно, если соответствующая реализация SQL их допускает). Комментарии полезны с точки зрения документирования, но слишком большое их число мешает понять суть оператора при чтении.

• При выборе нескольких столбцов в выражении ключевого слова SELECT имя каждого из столбцов лучше начинать с новой строки.

• При выборе нескольких таблиц в выражении ключевого слова FROM имя каждой из таблиц лучше начинать с новой строки.

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

Вот пример трудного для чтения оператора.

SELECT CUSTOMER_TBL.CUST_ID, CUSTOMERJTBL.CUST_NAME,

CUSTOMERJTBL.CUST_PHONE, ORDERSJTBL.ORD_NUM, ORDERS_TBL.QTY

FROM CUSTOMER_TBL, ORDERS_TBL

WHERE CUSTOMER_TBL.CUST_ID = ORDERSJTBL.CUST_ID

AND ORDERSJTBL.QTY > 1 AND CUSTOMERJTBL.CUST_NAME LIKE 'G%'

ORDER BY CUSTOMERJTBL.CUST_NAME;

CUST_ID CUST_NAME CUST_PHONE ORD_NUM QTY

----------------------------------------

287 GAVINS PLACE 3172719991 18D778 10

1 строка выбрана.

А вот пример того же оператора после форматирования с целью улучшения его восприятия.

SELECT C.CUST_ID,

С.CUST_NAME,

С.CUST_PHONE,

O.ORD_NUM,

О.QTY

FROM CUSTOMERJTBL С,

ORDERSJTBL О

WHERE C.CUST_ID = 0.CUST_ID

AND O.QTY > 1

AND С.CUST_NAME LIKE 'G%'

ORDER BY 2;

CUST_ID CUST_NAME CUST_PHONE ORD_NUM QTY

----------------------------------------------

287 GAVINS PLACE 3172719991 18D778 10

1 строка выбрана.

Оба оператора по сути одинаковы, но второй из них гораздо проще для чтения. Второй оператор упростился за счет использования псевдонимов таблиц, определенных в выражении ключевого слова FROM. Для выравнивания элементов выражений использовались пробелы, что выделило эти выражения среди других.

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

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

Проверьте по документации к используемой вами реализации SQL, нет ли в ней советов по поводу использования нескольких таблиц в списке ключевого слова FROM.