11.1. Введение#
11.1. Введение
Предположим, у нас есть таблица, похожая на эту:
CREATE TABLE test1 (
id integer,
content varchar
);
и приложение выполняет множество запросов следующего вида:
SELECT content FROM test1 WHERE id = constant;
Без предварительной подготовки система должна была бы просканировать всю таблицу test1 строка за строкой, чтобы найти все соответствующие записи. Если в таблице test1 много строк, а только несколько строк (возможно, ноль или одна) должны быть возвращены таким запросом, это явно неэффективный метод. Но если система была настроена на поддержку индекса на столбце id, она может использовать более эффективный метод для поиска соответствующих строк. Например, ей может потребоваться пройти только несколько уровней в глубину поискового дерева.
Подобный подход используется в большинстве научно-популярных книг: термины и концепции, которые читатели часто ищут, собираются в алфавитном указателе в конце документации. Интересующийся читатель может быстро просмотреть указатель и перейти на соответствующую страницу(ы), вместо того чтобы читать всю документацию, чтобы найти интересующий материал. Как и задача автора предвидеть термины, которые читатели, вероятно, будут искать, так и задача программиста баз данных предвидеть, какие индексы будут полезными.
Следующая команда может быть использована для создания индекса на столбце id, как обсуждалось:
CREATE INDEX test1_id_index ON test1 (id);
Имя test1_id_index может быть выбрано свободно, но вам следует выбрать что-то, что позволит вам запомнить позже, для чего был создан этот индекс.
Чтобы удалить индекс, используйте команду DROP INDEX.
Индексы могут быть добавлены и удалены из таблиц в любое время.
После создания индекса дальнейшее вмешательство не требуется: система будет обновлять индекс при изменении таблицы и использовать его в запросах, когда это будет более эффективно, чем последовательное сканирование таблицы. Однако, вам может потребоваться регулярно запускать команду ANALYZE, чтобы обновлять статистику и позволить планировщику запросов принимать обоснованные решения. См. раздел Глава 14 для получения информации о том, как узнать, используется ли индекс и когда и почему планировщик может выбрать не использовать индекс.
Индексы также могут быть полезными для команд UPDATE и DELETE с условиями поиска.
Индексы также могут использоваться в поиске с использованием объединений. Таким образом, индекс, определенный на столбце, который является частью условия объединения, также может значительно ускорить запросы с объединениями.
Создание индекса на большой таблице может занять много времени. По умолчанию, Tantor BE позволяет выполнять чтение (команды SELECT) на таблице параллельно с созданием индекса, но запись (команды INSERT, UPDATE, DELETE) блокируется до завершения построения индекса. В производственных средах это часто неприемлемо. Возможно разрешить выполнение записи параллельно с созданием индекса, но есть несколько оговорок, о которых следует знать — для получения дополнительной информации см. Building Indexes Concurrently.
После создания индекса система должна поддерживать его синхронизацию с таблицей. Это добавляет издержки на операции манипулирования данными. Индексы также могут предотвратить создание только в куче (heap-only tuples) кортежей. Поэтому индексы, которые редко или никогда не используются в запросах, следует удалить.