Подтвердить что ты не робот

Как узнать, когда индексировать столбец и с чем?

В документах для различных ORM они всегда предоставляют способ создания индексов и т.д. Они всегда упоминают, что обязательно создадут соответствующие индексы для эффективности, как если бы это было неотъемлемым знанием для не-рукописного-SQLer, который нуждается в использовать ORM. Мое понимание индексов (вне ПК) в основном: если вы планируете выполнять запросы LIKE (т.е. Поиск) на основе содержимого столбца, вы должны использовать полный текстовый индекс для этого столбца. Что еще я должен знать относительно индексов (в основном связанных с эффективностью)? Я чувствую, что на моем пороге есть мир знаний, но под ним застрял огромный складной коврик для мыши, поэтому я не могу пройти (я не знаю, почему я чувствовал, что мне нужно было это сказать, но спасибо за предоставление кушетки).

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Итак... вы бы создали индекс, когда у вас есть информация, которую вам нужно часто искать. Нормальные индексы не помогают вам "частично" искать как LIKE-запросы, но в любое время вам нужно получить набор результатов, в которых поле X имеет определенное значение (-ы), они не позволяют СУБД "сканировать" всю таблицу, ища соответствующие значения.

Они также помогают, когда вам нужно сортировать по столбцу.

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

Вы упомянули индексы Full Text и PK (первичные ключи). Они отличаются от обычных индексов, хотя они часто выполняют аналогичные задачи.

Во-первых, обратите внимание, что первичный ключ обычно является индексом (в MSSQL, "кластеризованным индексом" ), но это не обязательно так. Например, MSSQL PK является кластеризованным индексом по умолчанию; кластеризованные индексы являются особыми в том смысле, что они не являются отдельным битом данных, хранящихся в другом месте, но сами данные упорядочиваются в таблице по порядку с помощью кластерного индекса. Вот почему популярный PK - это значение int, которое автоматически генерируется с последовательными, увеличивающимися значениями. Таким образом, кластерный индекс сортирует данные в таблице, в частности, по значению поля. Сравните это с традиционным словарем; сами записи упорядочиваются "ключом", который является определяемым словом.

Но в MSSQL (проверьте свою документацию по СУБД для вашей информации), вы можете изменить Clustered Index, чтобы быть другим полем, если хотите. Иногда это делается на основе datetime.

Полнотекстовые индексы - это разные виды животных. Они используют одни и те же принципы, но то, что они делают, не совсем то же самое, что и обычные индексы, которые я описываю. Также: в некоторых СУБД запросы LIKE не используют полный текстовый индекс; требуются специальные операторы запроса.

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

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