выбираем С1. Таким образом, сначала присоединяем С1, а полный порядок соединения выглядит как (СЗ. ВЗ. А2. С2. D2, D1. С4. D3, С5. И. А1. В1. С1, 82).

ПРИМЕЧАНИЕ-

На самом деле последние несколько соединений слабо влияют на стоимость запроса, так как количество строк к этому моменту становится весьма небольшим.

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

Чтобы сделать скрытые фильтры соединений с С1 и D1 явными и использовать их как можно раньше в плане исполнения, добавьте в запрос условия С2.FkeyToDl IS NOT NULL AND Bl. FkeyToCl IS NOT NULL.

Теперь ослабьте требования надежного плана и подумайте, какие соединения должны проводиться методом хэширования и какой путь доступа нужно использовать для таблиц, соединяемых хэшированием. Вспомните, что в таблице А1 30 ООО ООО строк. Исходя из детальных коэффициентов соединения, в 81 и 82 должно быть в 300 раз меньше строк. То есть в обеих таблицах находится по 100 ООО записей. Исходя из комбинации главного коэффициента соединения и детального коэффициента соединения, в С1 в десять раз меньше строк, чем в В1, - 10 ООО. Переходя вверх от А1 к М, видим, что в М в 0,02 раза меньше строк, чем в А1, - 600 ООО. Спускаясь вниз от И и используя детальные коэффициенты соединения, вычислим, что в А2 и ВЗ по 60 ООО строк, в С2 30 ООО строк, в СЗ 10 ООО строк, в С4 20 ООО строк и в С5 12 ООО строк. Учитывая главный и детальный коэффициенты соединения от С2 к 01, вычислим, что в D16 ООО (30 ООО х 0,4/2) строк. Исходя из детальных коэффициентов соединения, найдем, что в D2 150 строк, а в D3 2 ООО строк.

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

ПРИМЕЧАНИЕ-

Как обсуждалось в главе 2, фактически порог для индексного доступа может находиться в любой точке между 0,5 и 20 %, но в этом упражнении граничным значением считается 5 %, чтобы сделать задачу конкретнее.

Итак, в таблице А. 1 показаны размеры таблиц и граничные значения для выбора полного сканирования таблицы, отсортированные в порядке соединения.

Таблица А.1. Размеры таблиц и пороги для выбора полного сканирования таблицы для решения упражнения из главы 6

Теперь, узнав количество строк на каждом шаге запроса, мы обнаруживаем, что после полного сканирования таблицы СЗ фильтр для СЗ сокрашает количество строк до 2000. Соединение вверх методом вложенных циклов с В1 затрагивает 12 ООО строк из этой таблицы, так как детальный коэффициент фильтрации равен 6. Для ВЗ нет фильтра, поэтому следующее соединение вида один к одному (в среднем) с А2 также затрагивает 12 ООО строк, после чего фильтр для А2 оставляет лишь 30 % (3600 строк) для следующего соединения с С2. Имея главный коэффициент соединения, равный 1.0, вложенные циклы затронут 3600 строк из С2. Фильтры для С2 (включая ставший явным фильтр не равен nulb по внешнему ключу к D1) сокращают количество строк до 1440 перед соединением с D2. Вложенные циклы для D2 считывают 1440 строк из этой таблицы, после чего фильтр оставляет 1008 строк. Вложенные циклы для D1 считывают 1008 строк из этой таблицы (так как на данный момент у всех строк есть не равные null внешние ключи, указывающие на D1), после чего фильтр оставляет 706 строк (я округляю это значение, что буду делать и в дальнейшем).

Вложенные циклы для С4 считывают 706 строк из этой таблицы, и они не фильтруются, оставляя количество строк равным 706. Вложенные циклы для D3 считывают 706 строк из этой таблицы, после чего фильтр оставляет 282. Вложенные циклы для С5 считывают 282 строки из этой таблицы, и они не фильтруются, оставляя количество строк равным 282. С детальным коэффициентом соединения равным 10, соединение вверх с М считывает 2820 строк из этой таблицы, после чего фильтр оставляет только 1410. С не указанным главным коэффициентом соединения равным 1,0, вложенные циклы считывают 1410 строк из самой большой таблицы, А1, и после этого фильтр оставляет 564 строки. Вложенные циклы для В1 считывают 564 строки из этой таблицы, после чего фильтры (включая ставшее явным условие внешний ключ не равен null по ключу В1, указывающему на С1) оставляют 28. Вложенные циклы для С1 считывают 28 строк из этой таблицы (так как на данный момент во всех строках есть внешние ключи, не равные null, которые ухсазыва-

ют на С1), после чего фильтр оставляет 3 записи. Вложенные циклы для В2 считывают 3 строки из этой таблицы, после чего итоговый фильтр оставляет О или 1 строку в качестве результата.

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

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

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