Сокращение поиска ключей
https://dba.stackexchange.com/questions/9124
-
16-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я использую SQL-сервер и внимательно изучил концепцию поиска ключей.
Итак, если у вас есть ключевой поиск, вы можете создать индекс со столбцами «include», чтобы охватить неиндексные столбцы, которые есть в операторе выбора.
Например,
SELECT ID, FirstName FROM OneIndex WHERE City = 'Las Vegas'
GO
Этот индекс будет включать в себя ключевой поиск,
CREATE NONCLUSTERED INDEX [IX_OneIndex_City] ON [dbo].[OneIndex]
(
[City] ASC
) ON [PRIMARY]
GO
Но этот удалит поиск ключа,
CREATE NONCLUSTERED INDEX [IX_OneIndex_Include] ON [dbo].[OneIndex]
(
City
) INCLUDE (FirstName,ID) ON [PRIMARY]
GO
Я имею в виду, какое влияние это окажет на производительность?Стоимость поиска ключа составляет 0,295969 (99%), но что это на самом деле означает?
Как узнать, что вам нужен второй индекс, и в какой момент становится так, что вы пытаетесь добавить слишком много индексов, и оно того не стоит?
Мне кажется, что некоторые запросы могут включать сканирование индекса, поиск ключей и при этом выполняются очень быстро.
Решение
Представьте себе, что у телефонной компании есть список телефонных номеров, в том числе то, кто является клиентом, где они живут, каков их биллинговый номер и так далее. Основным ключом может быть номер телефона.
Они дают вам белые страницы. Это как не кластеризованный индекс, который упорядочен по имени, включая столбцы, такие как адрес.
Если вы хотите найти всех фарли в книге и интересуйтесь их адресами, то белые страницы - это все, что вам нужно. Вы можете быстро обратиться к Фарли (найти FS, и так далее), а затем у вас есть вся необходимая информация.
Но если вы хотите их биллинговые номера, вам нужно сделать поиск. Вы можете быстро найти все телефонные номера фарли, но тогда вам нужно взять каждого из них (сотни) и сделать другой поиск (поиск) в главном (кластеризованном) индексе, который заказывается номером телефона. Каждый из них является примерно такой же стоимостью, что и стремление найти фарли, что усугубляет заказы на запрос на величину.
И есть порог. В какой -то момент база данных поймет, что это быстрее, просто чтобы пройти каждую страницу кластерного индекса, проверяя каждую запись, чтобы увидеть, интересно ли это.
Серьезно - избавьтесь от поисков. Ваши вопросы теперь могут быть быстрыми, но, вероятно, не будут масштабироваться.
Другие советы
Фон
в худший случай, запрос, содержащий поиск, должен отправляться в физическое хранилище для строк, которым требуются данные столбца, не охватываемые некластеризованным индексом.в очень худший В худшем случае для каждого поиска потребуется отдельный ввод-вывод, и перед продолжением выполнения придется ждать возврата данных, содержащихся в этой единственной строке.Этот сценарий обычно имеет серьезные последствия для производительности, если при поиске требуется обработать значительный количество рядов.
Вот почему о поисковых запросах так плохо отзываются в прессе.С другой стороны, учтите, что возможность поиска появилась в SQL Server 2000.В SQL Server 7.0 процессор запросов мог использовать некластеризованный индекс только в том случае, если он содержал все информация, необходимая для удовлетворения запроса;во всех остальных случаях ему приходилось обращаться к данным через кластерный индекс (если он присутствует, или через сканирование кучи в противном случае).Если бы поиск всегда был таким плохим, SQL Server наверняка никогда бы его не ввел.
Тогда в SQL Server 2000+, где у нас есть некластеризованный индекс, который обеспечивает полезный порядок и/или (большую часть) столбцов, требуемых запросом, и где количество поисков, вероятно, будет относительно небольшим, использование некластеризованного индекса и выполнение а ограниченное количество количества поисков в базовой таблице, вероятно, будет самым дешевым доступным методом доступа (хотя, конечно, некластеризованный индекс с полным покрытием может быть еще дешевле).
Во многих случаях это просто не практично создать столько некластеризованных индексов, сколько необходимо, чтобы избежать сканирования базовой таблицы для всех распространенных запросов.Одной из причин может быть то, что INSERT/UPDATE/DELETE/MERGE производительность важнее скорости запросов (помните, что операции изменения данных также должны поддерживать все затронутые некластеризованные индексы).Другой причиной может быть пространство;каждый некластеризованный индекс представляет собой копию подмножества столбцов базовой таблицы (или выражений в ней), просто отсортированных по-разному.Больше копий данных означает больше места для хранения и больше вещей, конкурирующих за место в кэше данных SQL Server.
В других случаях мы можем создать всего несколько дополнительных индексов (возможно, отфильтрованных в SQL Server 2008+) с достаточным количеством INCLUDE столбцы для удовлетворения подавляющего большинства запросов, критичных к производительности, без слишком большого ущерба для производительности модификации данных и без использования слишком большого количества дополнительного дискового пространства.Уравновешивание конкурирующих соображений — вот что делает настройку индекса скорее искусством, чем наукой.
Расходы
Вы спрашиваете, сколько на самом деле стоят 99% для оператора поиска. означает в плане запроса.Компонент расчета затрат оптимизатора запросов выдает оцененный стоимость этой операции составляет 99% от общей суммы оцененный для запроса.Само число (0,29) вообще ничего не значит;для всех практических целей вам следует рассматривать его как безразмерное число, используемое оптимизатором внутри себя при сравнении альтернативных стратегий для этого конкретного запроса.
Ориентировочная стоимость не учитывает ваше оборудование, конфигурацию, потребности приложений и многое другое.Модель затрат, используемая оптимизатором, включает значительное количество эвристик и упрощающих допущений, которые случаться для создания разумных планов большую часть времени, для большинства запросов, на большинстве аппаратных средств.Это не значит, что существует нет корреляция между дорогостоящими операторами в планах и производительности;скорее, связь часто намного слабее, чем обычно ожидалось.Во что бы то ни стало сначала проверьте причины завышения стоимости планов операторами, но не рассматривайте эту информацию как нечто иное, кроме весьма возможной ошибочной оценки.
Влияние
Я также хочу упомянуть пару факторов, которые могут улучшить влияние поиска.Во-первых, я с самого начала упомянул, что худший случай предполагает построчный физический ввод-вывод.Очевидно, этого можно избежать, если страницы данных (кластерный индекс или куча), необходимые для выполнения поиска, уже находятся в памяти (кэш данных).В этом случае разница во времени выполнения между планом с поиском и покрывающим индексом может оказаться неизмеримой.Даже там, где требуется физический ввод-вывод, если количество операций чтения невелико, вам все равно может быть все равно.(Насколько вероятно, что страницы данных для таблицы будут находиться в кэше данных, зависит от многих факторов и зависит от вашего оборудования и обстоятельств).
Там, где требуется больше, чем небольшой физический ввод-вывод, влияние поисков все равно можно уменьшить за счет оптимизации, присутствующей в плане запроса.Если SQL Server ожидает, что количество поисков будет значительным, он может выбрать явную сортировку строк, входящих в соединения вложенных циклов, приводя поиск в порядок некластеризованных ключей.Такое переупорядочение способствует последовательному чтению некластеризованного индекса, которое может быть намного быстрее, чем произвольный ввод-вывод на вашем оборудовании.
С явной сортировкой или без нее, вложенные циклы, ведущие поиск, могут иметь WithOrderedPrefetch или WithUnorderedPrefetch атрибуты присутствуют.В любом случае механизм выполнения запросов «просматривает» поток ключей индекса, вызывая поиск и проблемы. чтение вперед читает.Идея состоит в том, чтобы выдать асинхронный запросы на чтение к системе ввода-вывода страниц данных, которые понадобятся в ближайшее время, так что к тому моменту, когда для поиска потребуется страница данных, она уже будет присутствовать в памяти.
В идеальных условиях (низкая фрагментация, хороший план запроса, высокопроизводительная система ввода-вывода) механизм упреждающего чтения вполне может быть достаточно быстрым, чтобы предотвратить ожидание завершения ввода-вывода даже при больших планах параллельных запросов.Это особенно актуально для Enterprise Edition, которая может выдавать очень большие одиночные запросы ввода-вывода (до 2 МБ на запрос, если позволяет память).С другой стороны, в условиях, далеких от идеальных (более нормальных!), ваш запрос может сильно пострадать, поскольку он ожидает в длинных очередях ввода-вывода или не может достаточно сильно управлять системой ввода-вывода.В худшем случае производительность поиска ключей может быть очень низкой.
Краткое содержание
Подводя итог, вы будете в целом хочу избежать поисков где имеет смысл это сделать.Для небольших запросов (которые останутся небольшими) вы можете решить, что накладные расходы на дополнительные индексы (пространство и обслуживание) не оправданы, учитывая более широкие потребности системы и ее пользователей.
В конечном счете, все это часть искусства и науки, а именно разработка и администрирование баз данных.
