Отсутствует указатель Подробности SQL - программирование
Подтвердить что ты не робот

Отсутствует указатель Подробности SQL

Я настраиваю свой SQL-сервер, и когда я показываю свой план выполнения для одного из моих запросов в верхней части, он читает:

"Отсутствующий индекс (Impact 99.7782): СОЗДАТЬ НЕУКАЗАННЫЙ ИНДЕКС..."

Итак, я просмотрел недостающие данные индекса, и он показывает это:

/*
Missing Index Details from ExecutionPlan1.sqlplan
The Query Processor estimates that implementing the following index could improve the query cost by 99.7782%.
*/

/*
USE [phsprod]
GO
CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]
ON [dbo].[address] ([userid])

GO
*/

Я работаю только с SQL уже около месяца, и я никогда ничего не делал с этим, поскольку все мои таблицы уже созданы для меня. Может ли кто-нибудь помочь объяснить/дать мне какие-либо идеи о том, что с этим делать? Спасибо.

4b9b3361

Ответ 1

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

Чтобы создать индекс, раскомментируйте оператор после use, замените [<Name of Missing Index, sysname,>] на реальное имя и запустите его:

USE [phsprod]
GO
CREATE NONCLUSTERED INDEX IX_Address_UserId
ON [dbo].[address] ([userid])

Ответ 2

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

Это может означать, что ваши текущие индексы не самые большие для выполняемого вами запроса. Возможно, ваш запрос может быть оптимизирован. Или, может быть, вы МОЖЕТЕ добавить индекс. Но если вы решите сделать это, вы должны тщательно проанализировать.

Действительно, индексы добавляют служебные и дисковые хранилища. Но это также может повысить производительность. Например, если вы всегда выполняете поиск в своей таблице на основе "userid", то, возможно, он может заплатить, чтобы добавить индекс в этот столбец, поскольку SQL сможет выполнять поиск этого индекса.

Подумайте немного об этом, как если бы вы искали слово в словаре. Если вы ищете слово "собака" , вы собираетесь искать "d", а затем слова, начинающиеся с "do", чтобы наконец найти слово "собака" .

Если слова не были в алфавитном порядке в словаре, вам нужно было бы искать весь словарь, чтобы найти слово "собака" !

Кластеризованный индекс (или первичный ключ) - это порядок столбцов. Прямо сейчас, кажется, что у вас нет индекса в столбце "userid". Таким образом, SQL Server (возможно) сканирует всю таблицу, пока не найдет идентификатор пользователя.

Если вы добавите некластеризованный индекс, он не будет перенаправлять вашу таблицу, но он будет указывать SQL Server между тем диапазоном, который он должен искать, чтобы найти идентификатор пользователя, который вы хотите. (Как "в словаре, между страницами 20 и 30" ). Поэтому он не должен искать всю таблицу, чтобы найти ее.

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

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

Надеюсь, что это поможет!