Влияние неиспользованного индексации на производительность

На моем сайте я не создаю пользователей. Пользователи создаются в другой системе, к которой у меня нет доступа.Влияние неиспользованного индексации на производительность

Там они использовали Userid = VARCHAR (50)

С моей стороны, я держу очень простую таблицу, что-то вроде

UserId VARCHAR(50) 
Employer VARCHAR(4) 
UserSpecificField VARCHAR(8) 
DateWhenItWasAddedToOurSystem DATETIME

При входе в моей системе, я просто сделать простой SYNC, поэтому у меня есть все в моей системе. У меня 2000 записей в этой таблице.

Вопрос:

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

Добавляет индекс, способствующий повышению производительности, даже если вы не используете этот столбец ни для чего? Поскольку везде я использую ПОЛЬЗОВАТЕЛЬ, я вынужден использовать идентификатор пользователя VARCHAR (50) для создания SQL JOIN на основе.

Спасибо

источник

2013-03-15 Ash

У вас есть указатель на 'UserId' или' UserId' - первичный ключ? С 2000 записей индекс не будет сильно увеличивать ваше приложение. Однако при подключении или запросе для столбца вам поможет индекс. Существуют и другие зависимости: какие другие столбцы используются в таблице User, как часто обновляется таблица User и т. Д. BTW индекс в столбце, который никогда не использовался, является лишь нагрузкой на производительность для вставки, обновления и удаления. – Claude

На данный момент у меня нет индекса на этой таблице. Но есть и другая таблица с 1 млн. Записей, которая объединена с этим с помощью UserId Varchar (50) col – Ash

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

Положив рядом небольшого размера таблицы, нет никакого смысла в добавлении индекса на UserId в таблице этой структуры. Обратите внимание, что этот столбец (учитывая, что поле varchar (50) будет заполнено в среднем на 50%), этот единственный столбец будет составлять 70% от размера таблицы. Таким образом, движок db должен сначала сканировать индекс (который имеет почти размер таблицы enitre), а затем искать записи в таблице itsef. Эта операция будет более ресурсоемкой, чем просто сканирование таблицы. Я уверен, что оптимизатор не будет использовать индекс вообще. Испытай сам. Единственный вариант, на мой взгляд, заключается в добавлении кластерного индекса, который фактически «сортирует» вашу таблицу по UserId, делая запросы быстрее, и не накладывая лишних накладных расходов, создавая дополнительную структуру (т. Е. «Нормальный» индекс). Я предполагаю, что операция обновления не выполняется очень часто.

create unique clustered index idxCLU__userid on <your_table_name>(UserId)

источник

2013-03-15 09:28:21

Влияние неиспользованного индексации на производительность

ответ

Смежные вопросы