Время для извлечения отдельной записи с помощью индекса SQL Server в большой таблице

Question

Краткая версия вопроса:

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

Более длинная версия вопроса и фона:

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

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

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

Если вы создаете индекс по GUID клиентской записи и дате / времени доступа (по убыванию), то вы должны иметь возможность извлечь требуемую запись с помощью сканирования индекса, которое просто нужно найтипервая запись для этого GUID, а затем остановить?Кроме того, при использовании индекса b-дерева большая часть индекса будет кэшироваться, поэтому необходимое количество обращений к физическому диску будет очень небольшим, и, следовательно, время запроса будет значительно меньше 1 с.

Или я неправильно понял

Answer 1

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

Кроме того, в вашем подходе нет ничего плохого.Если таблица больше ОЗУ, у вас, скорее всего, будет один дисковый ввод-вывод для каждого доступа (промежуточные уровни индекса будут кэшироваться).Если ваши данные помещаются в оперативную память, вы будете платить от 0,2 до 0,5 мс за запрос.Если ваши данные находятся на магнитном диске, поиск, вероятно, потребует 8-12 мс.На SSD вы вернулись к значениям от 0,2 мс до 0,5 мс (возможно, больше на 0,05 мс).

Почему бы вам просто не создать тестовые данные (выбрав перекрестный продукт из sys.object из 1M строк) иизмерить это.Это займет немного времени, и вы узнаете наверняка.

Answer 2

Это зависит.

Один поиск будет недорогим и быстрым

• на приличной индексированной таблице
• работает на приличном оборудовании
• по приличной сети

С другой стороны, все же требуется время .

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

Некоторые вопросы, на которые нужно ответить

• Является ли мое оборудование до спецификации
• Результатом добавления двух полей является разбиение страницы (маловероятно)
• Сколько дополнительных страниц нужно прочитать для ваших обычных наборов результатов
• Сколько запросов / сек будет сделано
• Сколько вставок в секунду ( вызывает обновление индекса) будет сделано

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

Answer 3

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

Тогда я бы тоже волновался.

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

Answer 4

должно быть дешевым и быстрым, так как столбцы проиндексированы, и это будет O (n), я думаю