Наличие индекса для поля базы данных, которое является VARCHAR, может увеличить скорость вставок? - PullRequest
1 голос
/ 15 июля 2011

В моей базе данных есть две таблицы: страница и ссылка.В каждом из них я определяю, что поле URL УНИКАЛЬНО, потому что я не хочу повторных URL.

Будучи УНИКАЛЬНЫМ полем, оно автоматически имеет индекс?Создание индекса для этих полей может ускорить вставки?Какой индекс наиболее подходит для поля VARCHAR?

Наличие большого количества строк может замедлить вставку, потому что это УНИКАЛЬНОЕ поле?На данный момент у меня 1 200 000 строк.

Ответы [ 3 ]

2 голосов
/ 15 июля 2011

Логически говоря, ограничение - это одно, а индекс - другое. Ограничения связаны с целостностью данных; индексы имеют отношение к скорости.

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

Я полагаю, что индекс в столбце VARCHAR () может ускорить вставку при определенных обстоятельствах. Но, как правило, индекс замедляет вставки, потому что DBMS должен

  • проверьте все ограничения, затем
  • вставьте данные и, наконец,
  • обновить индекс.

Подходящий индекс ускорит обновления, потому что dbms может найти строки, которые будут обновлены быстрее. (Но может понадобиться обновить и индекс, что будет стоить вам немного.)

PostgreSQL может сказать вам, какие индексы он использует. См. ОБЪЯСНИТЬ .

2 голосов
/ 15 июля 2011

Да, добавление уникального ограничения создаст индекс :

Добавление уникального ограничения автоматически создаст уникальный индекс btree для столбца или группы столбцов, используемых в ограничении.

Это не ускорит ваши ВСТАВКИ, но фактически замедлит их:

  1. Каждая вставка должна быть проверена (с использованием индекса), чтобы гарантировать сохранение уникальности.
  2. Вставки также обновят индекс, и это не бесплатно.
1 голос
/ 15 июля 2011

Обычно b-tree / b + tree index являются наиболее распространенными индексами, и, скорее всего, вставки и обновления с этими индексами выполняются медленнее, тогда как выбор одной строки, выбор диапазонов и ORDER BY (в большинстве случаев по возрастанию)очень быстрый.Это потому, что этот индекс упорядочен, и поэтому вставка должна была бы выяснить, куда вставить, а не просто вставить его в конец таблицы.В случае кластеризованного индекса вставка / обновление еще хуже из-за разбиения страницы.

Уникальность, вероятно, сделает его немного медленнее, поскольку ему приходится сканировать больше строк, чтобы убедиться в его уникальности.

Кроме того, varchar, как правило, не лучший выбор для индексов, если вы ищете оптимальную производительность, целое число намного быстрее, если его можно использовать.Таким образом, на самом деле нет лучшего индекса для varchar, у каждого индекса есть свои сильные и слабые стороны, и всегда есть компромисс.Это действительно зависит от ситуации и того, что вы планируете с ней делать, вам нужны только вставки / обновления?Или вам также нужно сделать выбор?Это то, что вам нужно спросить.

...