Здравствуйте, Kvazimodo75, Вы писали:
K>Данные в этой таблице постоянно обновляются, поэтому я не добавляю индексы в неё специально.
Вы спрашиваете как ускорить, но при этом не следуете советам. В чем смысл вашего действа?
Померить impact индексов можно с помощью tuning adviser, который идет в комплекте с SSMS. Скармливаете ему trace запросов, он их прогоняет на базе и анализирует подсказки оптимизатора не в разрезе одного запроса, а в целом по всем запросам, попавшим в trace.
Здравствуйте, Kvazimodo75, Вы писали:
K>Данные в этой таблице постоянно обновляются, поэтому я не добавляю индексы в неё специально.
У вас там Андрей Ж. еще работает? Если да, то подойдите к нему и попросите объяснить влияние индексов
на вставку. Заодно по уровням изоляции спросите и по блокировкам.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, Kvazimodo75, Вы писали:
K>>Данные в этой таблице постоянно обновляются, поэтому я не добавляю индексы в неё специально. _AB>У вас там Андрей Ж. еще работает? Если да, то подойдите к нему и попросите объяснить влияние индексов _AB>на вставку. Заодно по уровням изоляции спросите и по блокировкам.
Понятия не имею. IT здесь очень не дружествен к другим людям.
Может они много чего и знают, но результат их работы отвратителен.
Эта одна из причин, почему я вернулся в программирование баз данных.
Здравствуйте, Alex.Che, Вы писали:
>> Данные в этой таблице постоянно обновляются, поэтому я не добавляю индексы в неё специально.
AC>Очень оригинальное решение. AC>Какова была первопричина принятия оного?
Прочитал в этих Ваших интернетах, в том числе на хабре, что частая перестройка индексов может породить большие проблемы.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Kvazimodo75, Вы писали:
K>>Данные в этой таблице постоянно обновляются, поэтому я не добавляю индексы в неё специально. S>Ну, я бы всё таки рискнул и посмотрел, насколько это ухудшит производительность вставки.
Я подумаю.
K>>Решил тем, что результат count удивительным образом совпадает с порциями изменяемых данных, поэтому подсчитывается триггером и пишется в отдельную таблицу. S>Вы и вправду думаете, что триггер с записью в отдельную таблицу будет значительно быстрее, чем обновление индекса? Почему?
В процессе диалога в этой ветке топика и размышлениями над проблемой увидел, что сценарий бизнес-процесса примерно такой:
сначала часто-часто меняем некоторый блок данных, потом замораживаем его состояние, потом часто-часто обращаемся к отчёту с тем самым count.
Так как я пока не придумал как отличить последнее изменение от всех остальных, и зная, что результат расчёта в какое-то время перестанет меняться — решение сбрасывать этот результат в другую таблицу мне показалось логичным.
Про индекс я подумаю, наверно, в мае, после отпуска поэкспериментирую.
G>Вы спрашиваете как ускорить, но при этом не следуете советам. В чем смысл вашего действа?
Набираюсь уму-разуму. Вот тут подсказали ранее неизвестное слово FILLFACTOR.
Такой мой путь познания.
G>Померить impact индексов можно с помощью tuning adviser, который идет в комплекте с SSMS. Скармливаете ему trace запросов, он их прогоняет на базе и анализирует подсказки оптимизатора не в разрезе одного запроса, а в целом по всем запросам, попавшим в trace.
Здравствуйте, Kvazimodo75, Вы писали:
K>Понятия не имею. IT здесь очень не дружествен к другим людям.
Да вроде вполне себе дружественный был года три-четыре назад.
K>Может они много чего и знают, но результат их работы отвратителен.
Может что и поменялось с тех пор, но тогда там команда была достаточно сильная.
Дурдом у вас там совсем на другом уровне находится и отвратителен результат работы
совсем других людей и подразделений.
K>Эта одна из причин, почему я вернулся в программирование баз данных.
Извините, но, судя по всему здесь Вами сказанному, слово "вернулся" слишком громкое.
Здравствуйте, Kvazimodo75, Вы писали:
K>Прочитал в этих Ваших интернетах, в том числе на хабре, что частая перестройка индексов может породить большие проблемы.
Не читайте хабры, читайте документацию и блоги признанных специалистов.
Здравствуйте, _ABC_, Вы писали:
K>>Эта одна из причин, почему я вернулся в программирование баз данных. _AB>Извините, но, судя по всему здесь Вами сказанному, слово "вернулся" слишком громкое.
"Ах, давно, знать, забыли в этой стране
Про отчаянного негодяя и жулика Хлопушу.
Смейся, человек! " (с) С. Есенин
Здравствуйте, Kvazimodo75, Вы писали:
K>Здравствуйте, gandjustas, Вы писали:
G>>Вы спрашиваете как ускорить, но при этом не следуете советам. В чем смысл вашего действа?
K>Набираюсь уму-разуму. Вот тут подсказали ранее неизвестное слово FILLFACTOR.
Он вам не поможет.
G>>Померить impact индексов можно с помощью tuning adviser, который идет в комплекте с SSMS. Скармливаете ему trace запросов, он их прогоняет на базе и анализирует подсказки оптимизатора не в разрезе одного запроса, а в целом по всем запросам, попавшим в trace. K>Как-нибудь попробую. Благодарю.
Он вам тоже скажет, что надо добавить индекс
Здравствуйте, Kvazimodo75, Вы писали:
K>Здравствуйте, gandjustas, Вы писали:
K>>>Набираюсь уму-разуму. Вот тут подсказали ранее неизвестное слово FILLFACTOR. G>>Он вам не поможет.
K>Сейчас может и нет. Зато я буду знать, что есть такая возможность. Разве плохо?
Ну вы знаете что есть индексы, вам от этого легче стало?
Важно применять, а не "знать".
Здравствуйте, Kvazimodo75, Вы писали:
K>В процессе диалога в этой ветке топика и размышлениями над проблемой увидел, что сценарий бизнес-процесса примерно такой: K> сначала часто-часто меняем некоторый блок данных, потом замораживаем его состояние, потом часто-часто обращаемся к отчёту с тем самым count.
Что мешает в таком случае скопировать данные в отдельную таблицу где будут индексы оптимизированные на поиск?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
