Добавление индекса к уже существующей таблице с данными

@UNGVAS · Регистрация: 30.12.2013

Студворк — интернет-сервис помощи студентам

Добрый ))

Есть таблица с уже 300 000 строк. Индексы отсутствуют и простой select запрос выполняется долго, решил добавить индекс по дате (Clustered тип datetime) и всё запросы выполнялись быстро. Через несколько времени заметил что запросы опять выполняются долго. Решил перестроить индекс и вуаля опять заработало и на меня дошло что каждый раз когда обновляется база то необходимо перестроить индекс.

Что я делаю не так? Как можно автоматизировать перестройку индексов?

Спасибо

@ksk · 01.04.2014, 19:38

Перестройка обычно не нужна, индекс апдейтится при вставке / модификации поля.

Я обычно делаю индекс так:

SQL
1
2
3
4
5
IF NOT EXISTS (SELECT * FROM sysindexes WHERE id = object_id(N'dbo.TimeZone') AND OBJECTPROPERTY(id, N'IsTable') = 1 AND name='IX_TT') BEGIN
  PRINT 'Создаётся индекс TimeZone.IX_TT'
  CREATE INDEX IX_TT ON dbo.TimeZone(T1,T2)
END
GO

Кластерным его не обязательно делать.

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

SQL
1
2
3
SELECT T1, T2 FROM dbo.TimeZone
    WITH( INDEX (IX_TT) )
    WHERE T1 BETWEEN '15:30:05.030' AND '15:30:05.045';

@invm · 01.04.2014, 21:18

Сообщение от ksk

Кластерным его не обязательно делать.

Как можно давать такой совет не видя ни запроса, ни DDL-таблиц?

Сообщение от ksk

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

Можете продемонстрировать?

UNGVAS, вы лучше актуальные планы выполнения покажите (в формате sqlplan) для медленного и быстрого вариантов.

@UNGVAS · 01.04.2014, 22:27 **[ТС]**

Ещё замечание: я использую Entity Framework и запросы выполняются долго только в приложении но если перестрою индекс то выполняется быстро.

Когда индекса небыло то обычный запрос выполнялся долго и в SQL management studio и в WebApi но после того как добавил индекс то в SQL management studio запрос выполняется быстро уже всегда но в приложении нужно переодически перестроить индекс

Спасибо за советы поппробую завтра и отпишусь ))

@ksk · 01.04.2014, 23:05

Сообщение от invm

Как можно давать такой совет не видя ни запроса, ни DDL-таблиц?

Чисто из практики обращения с метками времни - они могут быть не уникальны. Но таки да, согласен.

Сообщение от invm

Можете продемонстрировать?

Составной индекс по одному из полей и метки времени и другой составной индекс по тем же полям плюс ещё одно поле.

Были тормоза по полторы минуты, нашёл профайлером один запрос - и сотни тысяч reads на
SELECT TOP 1 по условию равенства ID и ORDER BY метка времени DESC.

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

По количеству записей - добавляется 25 строк в секунду с глубиной хранения 4 месяца.

Потом поискал запросы с использованием ненужного индекса (у меня по нему запросов не было), индекс оказался брошенным, удалили его. Хинт оставил на случай, если кто-нибудь ещё чего-нибудь добавит.

@invm · 02.04.2014, 00:21

Сообщение от ksk

Чисто из практики обращения с метками времни - они могут быть не уникальны.

Кластерный индекс не обязательно должен быть уникальным. А вот RID/Key Lookup, вытекающая из использования некластерного, весьма дорогая операция. Если интересно, пример:

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

T-SQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
use tempdb;
go
 
create table dbo.t (id int not null, v int null);
go
 
insert into dbo.t
select top (10000)
 row_number() over (order by char('a')),
 1
from
 master.dbo.spt_values a cross join
 master.dbo.spt_values b;
go
 
create clustered index IX_t__id on dbo.t (id);
go
 
set statistics xml, io on;
select count(v) from dbo.t where id between 1 and 2000;
set statistics xml, io off;
go
 
drop index dbo.t.IX_t__id;
create index IX_t__id on dbo.t (id);
go
 
set statistics xml, io on;
select count(v) from dbo.t where id between 1 and 2000;
set statistics xml, io off;
go
 
set statistics xml, io on;
select count(v) from dbo.t with (index = IX_t__id) where id between 1 and 2000;
set statistics xml, io off;
go
 
drop table dbo.t;
go

Обратите внимание на количество чтений.

Сообщение от ksk

Составной индекс по одному из полей и метки времени и другой составной индекс по тем же полям плюс ещё одно поле.
Были тормоза по полторы минуты, нашёл профайлером один запрос - и сотни тысяч reads на
SELECT TOP 1 по условию равенства ID и ORDER BY метка времени DESC.

Вы, наверное, что-то путаете или забыли как было дело. Для приведенного запроса подойдут индексы по (ID, [метка времени], ...), либо по ([метка времени], ...), но не (..., [метка времени], ...).Конечно, оптимизатор может промахнуться с выбором плана и индекса, особенно если статистика неактуальна. Но к ситуации ТС'а это не относится - у него индекс один.

@UNGVAS · 02.04.2014, 10:22 **[ТС]**

Совсем запутался... изменение в базу уже были а запросы быстрые значит причина в другом

Добавлено через 1 час 21 минуту
Теперь запросы идут медленно можно тестить.

Пробовал WITH( INDEX (IX_DATE) ) результата нет (

@ksk · 02.04.2014, 18:52

invm, спасибо. Конечно, интересно. Доживу до выходного - попрофилирую. Со статистиками не работал ни разу.
Возможно, я не вполне помню, как было дело, так запомнилось. Было такое: (ID, [метка времени], ...), либо по ([метка времени], ...), при указании в хинте на второй вариант всё прошло.

И у меня всё ещё есть подозрение, что мы не можем точно знать, сколько у ТС индексов, пока он их явным образом не посчитает )

UNGVAS, если у Вас Ентить, то я отойду в тень, ибо это не моя поляна. Возможно, не в SQL части дело, а в том, как ОРМ готовит запросы. Единственное, что я бы тут сделал - профайлером бы посмотрел, какие запросы ОРМ реально отправляет серверу, какие получчабтся накладные расходы. Спринтскринил бы план выполнения запроса, и уже показывая эту информацию задавал бы вопросы специалистам по SQL. Может тормоза вообще не в SQL, а в ентитях коренятся.

@invm · 02.04.2014, 20:15

Сообщение от ksk

Доживу до выходного - попрофилирую. Со статистиками не работал ни разу.

Не надо ничего профилировать - просто выполнить скрипт: планы будут в результатах, статистика IO на вкладке Messages.

Сообщение от ksk

Единственное, что я бы тут сделал - профайлером бы посмотрел, какие запросы ОРМ реально отправляет серверу, какие получчабтся накладные расходы. Спринтскринил бы план выполнения запроса, и уже показывая эту информацию задавал бы вопросы специалистам по SQL. Может тормоза вообще не в SQL, а в ентитях коренятся.

+1
Только планы не принтскринить, а сохранять в файлы формата sqlplan.

Новые блоги и статьи Все статьи Все блоги /
Настройка движения справочника по регистру сведений Maks 29.03.2026 Решение ниже реализовано на примере нетипового справочника "ТарифыМобильнойСвязи" разработанного в конфигурации КА2, с целью учета корпоративной мобильной связи в коммерческом предприятии. . . .	Автозаполнение реквизита при выборе элемента справочника Maks 27.03.2026 Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. При выборе "Спецтехники" (Тип Справочник. Спецтехника), заполняется. . .	Сумматор с применением элементов трёх состояний. Hrethgir 26.03.2026 Тут. https:/ / fips. ru/ EGD/ ab3c85c8-836d-4866-871b-c2f0c5d77fbc Первый документ красиво выглядит, но без схемы. Это конечно не даёт никаких плюсов автору, но тем не менее. . . всё может быть. . .	Автозаполнение реквизитов при создании документа Maks 26.03.2026 Программный код из решения ниже размещается в модуле объекта документа, в процедуре "ПриСозданииНаСервере". Алгоритм проверки заполнения реализован для исключения перезаписи значения реквизита,. . .
Команды формы и диалоговое окно Maks 26.03.2026 1. Команда формы "ЗаполнитьЗапчасти". Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. В качестве источника данных. . .	Кому нужен AOT? DevAlt 26.03.2026 Решил сделать простой ланчер Написал заготовку: dotnet new console --aot -o UrlHandler var items = args. Split(":"); var tag = items; var id = items; var executable = args;. . .	Отправка уведомления на почту при создании или изменении элементов справочника Maks 24.03.2026 Программная отправка письма электронной почты на примере типового справочника "Склады" в конфигурации БП3. Перед реализацией необходимо выполнить настройку системной учетной записи электронной. . .	модель ЗдравоСохранения 5. Меньше увольнений- больше дохода! anaschu 24.03.2026 Теперь система здравосохранения уменьшает количество увольнений. 9TO2GP2bpX4 a42b81fb172ffc12ca589c7898261ccb/ https:/ / rutube. ru/ video/ a42b81fb172ffc12ca589c7898261ccb/ Слева синяя линия -. . .

@UNGVAS 0 / 0 / 0 Регистрация: 30.12.2013 Сообщений: 9

	Добавление индекса к уже существующей таблице с данными 01.04.2014, 12:26. Показов 9556. Ответов 8 Метки нет (Все метки) Добрый )) Есть таблица с уже 300 000 строк. Индексы отсутствуют и простой select запрос выполняется долго, решил добавить индекс по дате (Clustered тип datetime) и всё запросы выполнялись быстро. Через несколько времени заметил что запросы опять выполняются долго. Решил перестроить индекс и вуаля опять заработало и на меня дошло что каждый раз когда обновляется база то необходимо перестроить индекс. Что я делаю не так? Как можно автоматизировать перестройку индексов? Спасибо 0

@UNGVAS 0 / 0 / 0 Регистрация: 30.12.2013 Сообщений: 9
	01.04.2014, 22:27 [ТС]
	Ещё замечание: я использую Entity Framework и запросы выполняются долго только в приложении но если перестрою индекс то выполняется быстро. Когда индекса небыло то обычный запрос выполнялся долго и в SQL management studio и в WebApi но после того как добавил индекс то в SQL management studio запрос выполняется быстро уже всегда но в приложении нужно переодически перестроить индекс Спасибо за советы поппробую завтра и отпишусь )) 0

@UNGVAS 0 / 0 / 0 Регистрация: 30.12.2013 Сообщений: 9
	02.04.2014, 10:22 [ТС]
	Совсем запутался... изменение в базу уже были а запросы быстрые значит причина в другом Добавлено через 1 час 21 минуту Теперь запросы идут медленно можно тестить. Пробовал WITH( INDEX (IX_DATE) ) результата нет ( 0

@ksk 624 / 495 / 43 Регистрация: 05.07.2010 Сообщений: 1,589
	02.04.2014, 18:52
	invm, спасибо. Конечно, интересно. Доживу до выходного - попрофилирую. Со статистиками не работал ни разу. Возможно, я не вполне помню, как было дело, так запомнилось. Было такое: (ID, [метка времени], ...), либо по ([метка времени], ...), при указании в хинте на второй вариант всё прошло. И у меня всё ещё есть подозрение, что мы не можем точно знать, сколько у ТС индексов, пока он их явным образом не посчитает ) UNGVAS, если у Вас Ентить, то я отойду в тень, ибо это не моя поляна. Возможно, не в SQL части дело, а в том, как ОРМ готовит запросы. Единственное, что я бы тут сделал - профайлером бы посмотрел, какие запросы ОРМ реально отправляет серверу, какие получчабтся накладные расходы. Спринтскринил бы план выполнения запроса, и уже показывая эту информацию задавал бы вопросы специалистам по SQL. Может тормоза вообще не в SQL, а в ентитях коренятся. 0