стоимость некластеризованных индексов

Question

Если я создаю некластеризованный индекс для таблицы, SQL-сервер создает копию данных в этой таблице и сохраняет ее отдельно?Я просто думаю о стоимости создания некластеризованных индексов.Я предполагаю, что выбранный этим ключом, который используется в index, будет быстрее, но все вставки, обновления и удаления будут медленными, так как серверу sql придется поддерживать две копии данных.Правильно ли мое понимание?

Answer 1

SQL Server не будет копировать все данные в таблице, только данные, содержащиеся в столбцах индекса и любых «покрывающих» столбцах, плюс дополнительные служебные данные.

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

Answer 2

Данные не «копируются» для некластеризованных индексов. Создана «карта» сортов (иногда использующая полную копию только индексированного столбца [s]), чтобы ускорить поиск по некоторым запросам в этом поле. Для основного руководства к этому, подумайте о B-Tree http://en.wikipedia.org/wiki/B-tree где различные узлы находятся в хорошо известных местах и ​​что вы можете определить, исходя из запроса, с чего начать поиск. Да, вам нужно потратить некоторые ресурсы на создание / обслуживание карты ... но сколько времени вы тратите на поиски?

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

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

Answer 3

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