Индексы сосут в SQL?

Question

Скажем, у меня есть таблица с большим количеством строк и один из столбцов, которые я хочу проиндексировать, может иметь одно из 20 значений. Если бы я поместил индекс в столбец, был бы он большим?

Если так, то почему? Если бы я разбил данные на 20 таблиц, по одной на каждое значение столбца, размер индекса был бы тривиальным, но эффект индексации был бы таким же.

Answer 1

Индексы (или индексы) не отстой. Многие очень умные люди потратили поистине замечательное количество времени в последние несколько десятилетий, чтобы убедиться, что это так.

Однако вашей схеме, не обладающей таким же количеством опыта и усилий, действительно может быть очень плохо.

Разделение в описанном случае эквивалентно применению кластерного индекса. Если таблица отсортирована иначе (или в произвольном порядке), тогда индекс обязательно должен занимать гораздо больше места. В зависимости от платформы некластеризованный индекс может уменьшаться в размере по мере увеличения сортировки строк по отношению к индексированному значению.

YMMV.

Answer 2

Это не индексы, которые будут сосать. Это помещает индексы в неправильные столбцы, которые будут сосать.

Если серьезно, зачем вам таблица с одним столбцом? Каков будет смысл этих данных? Какой цели это будет служить?

а 20 таблиц? Я предлагаю вам сначала прочитать дизайн базы данных или иным образом объяснить нам контекст вашего вопроса.

Answer 3

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

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

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

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

Определите первичный ключ вашей таблицы, SQL автоматически поместит кластерный индекс в этот столбец (столбцы). Кластерные индексы работают очень хорошо. Кроме того, вы можете размещать некластеризованные индексы в столбцах, которые часто используются в инструкциях SELECT, JOIN, WHERE, GROUP BY и ORDER BY. Помните, что индексы имеют определенное перекрытие, старайтесь никогда не включать ваш кластеризованный индекс в некластеризованный индекс.

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

Третье: разбиение
Одной из причин использования секционирования является оптимизация доступа к данным. Допустим, у вас есть 1 миллион записей, из которых 500 000 записей больше не актуальны, но хранятся в целях архивирования. В этом случае вы можете разделить таблицу и сохранить 500 000 старых записей в медленном хранилище, а остальные 500 000 записей - в быстром.

Для измерения это знать
Лучший способ понять, что происходит, - это измерить, что происходит с вашим процессором и компьютером. Microsoft SQL Server имеет некоторые инструменты, такие как профилировщик и планы выполнения в Management Studio, которые сообщат вам продолжительность вашего запроса, количество операций чтения / записи и использования процессора. Также план выполнения скажет вам, какие индексы или IF используются. К вашему удивлению вы можете увидеть сканы таблицы, хотя вы этого не ожидали.

Answer 4

Краткий ответ: Индексы отстой: да и нет

Более длинный ответ: Они не сосут при правильном использовании. Может быть, вам стоит начать читать о том, как работают индексы, почему они могут работать и почему они иногда не работают.

Хорошие отправные точки: http://www.sqlservercentral.com/articles/Indexing/

Answer 5

Стандартные индексы b-дерева лучше всего подходят для довольно селективных индексов, чего в этом примере не было бы. Вы не говорите, какую СУБД вы используете; У Oracle есть другой тип индекса, называемый индексом битовой карты, который больше подходит для индексов с низкой селективностью в средах OLAP (поскольку эти индексы дороги в обслуживании, что делает их неподходящими для сред OLTP).

Оптимизатор решает на основе статистики, считает ли он, что индекс поможет получить данные в кратчайшие сроки; если это не так, optmiser не будет использовать его.

Разделение - это еще одна стратегия. В Oracle вы можете определить таблицу как секционированную по некоторому набору столбцов, и оптимизатор может автоматически выполнить «удаление разделов», как вы предлагаете.

Answer 6

Скажем, у меня есть таблица с большим количеством строк и одним столбцом, который я хочу проиндексировать, может иметь одно из 20 значений. Если бы я поместил индекс в столбец, был бы он большим?

Размер индекса будет пропорционален количеству строк и длине индексированных значений.

Индекс хранит не только индексированное значение, но и некоторый указатель на строку (ROWID в Oracle, LCID в PostgreSQL, первичный ключ в InnoDB и т. Д.).

Если у вас есть 10,000 строк и 1 отдельное значение, у вас все равно будет 10,000 записей в вашем индексе.

Если так, то почему? Если бы я разбил данные на данные в 20 таблиц, по одной на каждое значение столбца, размер индекса был бы тривиальным, но эффект индексации был бы таким же

В этом случае у вас будет 20 индексов, которые по размеру будут соответствовать вашему исходному.

Эта техника иногда фактически используется в так называемых секционированных индексах. У него есть свои преимущества и недостатки.

Answer 7

Извините, я не совсем уверен, что вы подразумеваете под "большим".

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

• Если ваш индекс не кластеризован, то на ваших конечных страницах будут находиться только данные, связанные с индексом. Затем, в зависимости от таких вещей, как количество других ваших индексов в сочетании с такими деталями, как ваш коэффициент заполнения, ваш индекс может быть или не быть эффективным. В общем, если у вас нет тонны индексов на вашем столе, вы должны быть в безопасности.

• Эффективность вашего индекса также будет определяться типом данных из 20 значений, о которых вы говорите в столбце. Если это предопределенные значения, то их данные, вероятно, должны быть в таблице поиска с простым типом данных первичного ключа (например, Int / Number). Затем добавьте этот столбец в таблицу в качестве внешнего ключа с индексом в столбце.

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

Answer 8

Это было бы достаточно большим, чтобы хранить эти значения для всех строк в отсортированном порядке.

Скажем, у вас есть 20 различных строк по 4 символа и 1 миллион строк, для хранения этих значений потребуется не менее 4 миллионов байтов (или 8, если используется 16-битный юникод).

Answer 9

Индексы предназначены исключительно для производительности. Если индекс не повышает производительность по интересующим вас запросам, то это отстой.

Что касается использования диска, вы должны взвесить ваши проблемы. Различные поставщики SQL строят индексы по-разному, но, как клиент, вы, как правило, уверены, что они делают все возможное, что можно сделать. В случае, если вы описываете, кластеризованный индекс может быть оптимальным как для размера, так и для производительности.