Программирование >>  Полное сканирование таблицы 

1 ... 57 58 59 [ 60 ] 61 62 63 ... 107


откоррею-ированных коэффициентов фильтрации для А1 и В1. Что присоединять дальше? Если вы проводите соединение с не фильтрованной стороны фильтрующего главного соединения, сделайте скрытый фильтр явным, указав условие не null для ForeignKeyToBl. Когда вы превращаете этот фильтр в явный, то у соединения оставшихся строк эффективный коэффициент соединения становится равным всего лишь 1,0, как у большинства главных соединений. Исправленная диаграмма SQL показана на рис. 6.28.

М 0.001



В10.8 В20.2

А1 0.5 А2 0.3

Рис. 6.27. Еще ОДИН запрос с фильтрующим главным соединением

М 0.001



А10.5x0.4 А20.3

810.8 82 0.2

Рис. 6.28. Исправление диаграммы, для установки явного фильтра главного соединения

Теперь становится понятно, что у А1 фильтр лучше, чем у А2, поэтому сначала присоединяем А1. После обработки А1 база данных может выбрать для следующего соединения также В1 или 82. Сравнивая их с А2, мы опять находим вариант лучше А2. Присоединяем В2, поскольку уже использовали преимущество фильтрующего соединения для В1. Полный оптимальный порядок в таком случае (М. А1. В2. А2. В1. ВЗ).

Теперь рассмотрите более сложную задачу на рис. 6.29 и попьггайтесь решить ее самостоятельно перед тем, как продолжать чтение.

Рассматривая в первую очередь наилучший эффе1сгивный фильтр, скоррисги-руйте коэффициент фильтрации для А1 и коэффициенты фильтрации ниже фильтрующего главного соединения. Тепфь для С1 эффективный фильтр равен 0,1 х 0,02 = = 0,002. Можно было бы сделать этот фильтр явным для А1, как в предыдущих примерах, указав условие не null для внешнего ключа, указывающего на В2, но это не смогло бы добавить А1 достаточно селективности, чтобы сделать его лучше С1. Прочие варианты - это не прошедшие коррисгировку коэффициенты для других узлов. Лучший из них - 0,005 для М. Этот коэффициент не настолько хорош, как эффективный ведущий фильтр для С2, поэтому ведущей таблицей выбираем



С2. Теперь фильтрующее главное соединение уже не имеет значения, поскольку база данных не будет выполнять соединения в этом направлении, и полный порядок соединения становится (С1. В2. А1, В1. М. А2, ВЗ).

М 0.005


А10.1 А2

t0.1 V В10.5 820.04 83

С1 0.02

Рис. 6.29. Еще один запрос с фильтрующим главным соединением

Как бы изменилась ситуация, если бы коэффициент фильтрации для А1 равнялся 0,01? Превращая подразумеваемое условие не null для Forei дпКеуТоВ2 в явное в SQL-коде, как в предыдущих примерах, можно было бы сделать селективность фильтра с несколькими условиями равной 0,1 х 0,01 = 0,001, лзд1ше, чем эффективный коэффициент фильтрации для С1. Так, А1 стала бы ведущей таблицей. После того как фильтр соединения сгорел , можно выбирать порядок соединения на основе простых коэффициентов фильтрации. Этот порядок: (А1. В2. С1. В1. М. А2. ВЗ).

Близкие коэффициенты фильтрации

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

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

В полезных запросах редко бывает много фильтров, обычно их от одного до трех.

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



ПРИМЕЧАНИЕ

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

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

При сравнении узлов при выборе ведущей таблицы сравнивайте абсолютные значения коэффициентов фильтрации напрямую. Значения 0,01 и 0,001 не близки, а различаются на порядок. Близкие значения для ведущего фильтра практически никогда не встречаются, кроме случаев, когда приложение опрашивает небольшие таблицы либо без фильтров, либо только с фильтрами средней селективности. В случае запросов, которые обращаются только к небольшим таблицам, редко бывает необходимо настраивать запрос. Автоматическая оптимизация легко выдает быстрый план.

ПРИМЕЧАНИЕ

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

Если один фильтр намного селективней остальных, выбор ведущей таблицы становится очень простым.

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

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

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

Сначала обрабатывайте небольшие таблицы. После того, как вы выбрали ведущую таблицу, реальное соотношение преимуществ и стоимости соединения со следующей главной таблицей равно (1 - R)/C, где R - коэффициент фильтрации, а С - стоимость считывания одной строки из этой таблицы через первичный ключ. Небольшие таблицы лучше кэшированы и у них обычно меньше уровней индекса, что уменьшает С и улучшает соотношение преимуществ и стоимости для маленьких таблиц.



1 ... 57 58 59 [ 60 ] 61 62 63 ... 107

© 2006 - 2024 pmbk.ru. Генерация страницы: 0.001
При копировании материалов приветствуются ссылки.
Яндекс.Метрика