Замена ограничений уникальности уникальными индексами
Пересказ статьи Erik Darling. Replacing Unique Constraints With Unique Indexes
Следует ли?
Я люблю, когда уникальность применяется правильно. Она может быть полезна не только для защиты от плохих данных, но также помогает оптимизатору в оценке количества строк, когда вы соединяете или фильтруете такие данные.
Но дело в том, что я не вполне согласен с тем, как большинство людей её настраивает, то есть путем создания уникального ограничения.
Уникальные ограничения поддерживаются некластеризованными индексами, но они значительно более ограничены в том, что вы могли бы с ними делать.
Например, вы не можете применить определение фильтра, или иметь в них включенные столбцы. А зачастую эти вещи делают данные, которые вы определяете как уникальные, более полезными.
Вот что я вижу довольно часто: ограничение уникальности на единственном столбце, а затем некластеризованный индекс на этом же столбце плюс включенные столбцы.
Поэтому теперь вы имеете два индекса на этом столбце, только один из них уникальный, и только один из них будет использован в запросах в качестве источника данных.
Ограничение уникальности может по-прежнему использоваться для оценки кардинальности, но сама структура просто сидит и потребляет запись весь день напролет.
В этом случае почти всегда лучше использовать уникальный некластеризованный индекс с включенными столбцами.
Конечно, это не работает, если вы имеете один столбец, который должен быть уникальным, а вам нужны несколько столбцов в ключе некластеризованного индекса. Однако мы не об этом говорим сейчас.
То, что вы можете добавить предложение where в индексы, до сих пор еще является новостью для некоторых людей, и это замечательно.
Часто фильтры применяются для изоляции и индексации определенных частей ваших данных, которые наиболее часто используются, или получения того преимущества от наличия гистограммы статистики, построенной специально на и для них, которая не содержит некоторых из 201 шагов, которые испорчены или подвержены влиянию данных за пределами фильтра.
Последний сценарий хорош для искаженных или перекошенных данных, которые неточно отображаются на гистограмме даже при полном сканировании (вероятно, довольно большой таблицы).
Но еще одним хорошим использованием является отфильтровывание только той порции уникальных данных, которые вас интересуют. Примером может служить таблица, которая имеет множество строк пользовательских сессий, но только одна сессия может быть активной. Наличие уникального фильтрованного индекса на пользователях с фильтрацией только по активным поможет вам быстрей перейти к той проблеме, которая вас заботит.
Если вы когда-нибудь выполняли sp_BlitzIndex и видели дублирующиеся или пересекающиеся индексы, некоторые из них могут быть ограничениями уникальности или индексами.
Не бойтесь смешивать семантически эквивалентные ограничения и индексы. Просто обязательно соблюдайте правила порядка ключевых столбцов и все такое.
Уникальные ограничения поддерживаются некластеризованными индексами, но они значительно более ограничены в том, что вы могли бы с ними делать.
Например, вы не можете применить определение фильтра, или иметь в них включенные столбцы. А зачастую эти вещи делают данные, которые вы определяете как уникальные, более полезными.
Батарейка в комплекте
Вот что я вижу довольно часто: ограничение уникальности на единственном столбце, а затем некластеризованный индекс на этом же столбце плюс включенные столбцы.
Поэтому теперь вы имеете два индекса на этом столбце, только один из них уникальный, и только один из них будет использован в запросах в качестве источника данных.
Ограничение уникальности может по-прежнему использоваться для оценки кардинальности, но сама структура просто сидит и потребляет запись весь день напролет.
В этом случае почти всегда лучше использовать уникальный некластеризованный индекс с включенными столбцами.
Конечно, это не работает, если вы имеете один столбец, который должен быть уникальным, а вам нужны несколько столбцов в ключе некластеризованного индекса. Однако мы не об этом говорим сейчас.
Фильтр
То, что вы можете добавить предложение where в индексы, до сих пор еще является новостью для некоторых людей, и это замечательно.
Часто фильтры применяются для изоляции и индексации определенных частей ваших данных, которые наиболее часто используются, или получения того преимущества от наличия гистограммы статистики, построенной специально на и для них, которая не содержит некоторых из 201 шагов, которые испорчены или подвержены влиянию данных за пределами фильтра.
Последний сценарий хорош для искаженных или перекошенных данных, которые неточно отображаются на гистограмме даже при полном сканировании (вероятно, довольно большой таблицы).
Но еще одним хорошим использованием является отфильтровывание только той порции уникальных данных, которые вас интересуют. Примером может служить таблица, которая имеет множество строк пользовательских сессий, но только одна сессия может быть активной. Наличие уникального фильтрованного индекса на пользователях с фильтрацией только по активным поможет вам быстрей перейти к той проблеме, которая вас заботит.
Очистка
Если вы когда-нибудь выполняли sp_BlitzIndex и видели дублирующиеся или пересекающиеся индексы, некоторые из них могут быть ограничениями уникальности или индексами.
Не бойтесь смешивать семантически эквивалентные ограничения и индексы. Просто обязательно соблюдайте правила порядка ключевых столбцов и все такое.
Обратные ссылки
Нет обратных ссылок
Автор не разрешил комментировать эту запись
Комментарии
Показывать комментарии Как список | Древовидной структурой