Здравствуйте, Kvazimodo75, Вы писали:
K>Есть таблица в которой довольно часто меняются данные (вставка, обновление, удаление). K>И тут понадобилось сделать count(a) where person_id in .... K>в результате время выполнения запроса — 7 минут K>Что можно придумать, чтобы работало быстро? (приемлемо секунд 30)
1) Если нужно просто посчитать количество строк, где person_id = ..., то лучше считать count(person_id)
2) Covering index (person_id, a)
3) Index on person_id include (a)
Здравствуйте, Kvazimodo75, Вы писали:
K>в результате время выполнения запроса — 7 минут
Для начала следует разобраться, на что СУБД тратит эти семь минут. Для этого есть всякие разные инструменты, описанные в performance tuning guide тщательно скрываемого Вами сервера.
K>Что можно придумать, чтобы работало быстро? (приемлемо секунд 30)
Придумать можно много, но как бы ежу понятно, что в случаях "в таблице 1.000.000.000 записей" и "в таблице 100 записей" правильные действия будут немного разными.
Здравствуйте, Kvazimodo75, Вы писали:
K>Есть таблица в которой довольно часто меняются данные (вставка, обновление, удаление).
K>И тут понадобилось сделать count(a) where person_id in ....
K>в результате время выполнения запроса — 7 минут
K>Что можно придумать, чтобы работало быстро? (приемлемо секунд 30)
1. Не делать count(*). Обычно это реально никому не надо.
2. Вести статистику в отдельной таблице, может быть даже не в СУБД, например при старте сервера считать число строк и потом хранить это значение в оперативной памяти сервера (если у нас не кластер). В связи с транзакциями, откатами и тд значение может быть неточным, но для миллионов обычно интересен примерный порядок, а не точное значение.
2.1. Использовать служебные данные из статистики БД.
По факту count(*) это тяжёлая операция, если её делать корректно и таблица большая и от этого никуда не деться.
Здравствуйте, Kvazimodo75, Вы писали:
K>Есть таблица в которой довольно часто меняются данные (вставка, обновление, удаление).
K>И тут понадобилось сделать count(a) where person_id in ....
K>в результате время выполнения запроса — 7 минут
K>Что можно придумать, чтобы работало быстро? (приемлемо секунд 30)
select count(a)from tablea with(nolock)
where person_id in
K>Что можно придумать, чтобы работало быстро? (приемлемо секунд 30)
Кроме вышесказанного — еще раз посмотреть, что там в in. В некоторых случаях эффективнее exists. Иногда (если там подзапрос) внутреннее соединение.
Может слишком большой список пытаетесь запихнуть в in.
Здравствуйте, Kvazimodo75, Вы писали:
K>Есть таблица в которой довольно часто меняются данные (вставка, обновление, удаление).
... K>Что можно придумать, чтобы работало быстро? (приемлемо секунд 30)
Потрясающе. Люди уже дают советы, но при этом что за запрос, или что за СУБД хотя бы — никто даже не уточнил
Здравствуйте, Kvazimodo75, Вы писали:
K>Есть таблица в которой довольно часто меняются данные (вставка, обновление, удаление).
K>И тут понадобилось сделать count(a) where person_id in ....
K>в результате время выполнения запроса — 7 минут
K>Что можно придумать, чтобы работало быстро? (приемлемо секунд 30)
vsb>1. Не делать count(*). Обычно это реально никому не надо.
Где Вы видели звездочку?
vsb>2. Вести статистику в отдельной таблице, может быть даже не в СУБД, например при старте сервера считать число строк и потом хранить это значение в оперативной памяти сервера (если у нас не кластер). В связи с транзакциями, откатами и тд значение может быть неточным, но для миллионов обычно интересен примерный порядок, а не точное значение.
Нужно точное значение
vsb>2.1. Использовать служебные данные из статистики БД.
Здравствуйте, Kvazimodo75, Вы писали:
K>Быстрый селект. K>Без count тот же запрос выполняется за 0-1 секунду.
Делаю предположение, что count(cpl1.id) — это и есть count(a)?
Идет скан всей таблицы для получения cpl1.id и последующий nested join.
Одним из возможных решений является создание индекса, который подсказывает план.
Скачайте SQL Sentry Plan Explorer и прогоните запрос там. У него есть функция анонимизации
плана в бесплатной версии. После анонимизации можно без особой опаски выложить полный план
в виде отдельного файла, а не скриншота.
Здравствуйте, Kvazimodo75, Вы писали: K>Сервер MS SQL 2014. K>План запроса:
1. План — от какого-то совсем другого запроса. В кроме count() есть много всего прочего, что влияет на стоимость.
2. Удивительным образом, на плане прямо написан совет, как ускорить ваш запрос.
Вы пробовали этот совет применить?
K>Количество записей исчисляется десятками тысяч — вроде как не много совсем.
K>Примерный результат не допустим.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>1. План — от какого-то совсем другого запроса. В нём вообще нет count(). Зато есть много всего
Да не, есть у него там ближе к правому краю картинки: count(cpl1.cpid)
PS Но давать план запроса в таком виде это форменное издевательство.
Здравствуйте, Sinclair, Вы писали:
S>1. План — от какого-то совсем другого запроса. В кроме count() есть много всего прочего, что влияет на стоимость. S>2. Удивительным образом, на плане прямо написан совет, как ускорить ваш запрос. S>Вы пробовали этот совет применить?
Данные в этой таблице постоянно обновляются, поэтому я не добавляю индексы в неё специально.
Решил тем, что результат count удивительным образом совпадает с порциями изменяемых данных, поэтому подсчитывается триггером и пишется в отдельную таблицу.
Исходный запрос изменён на left outer join с этой отдельной таблицей.
Здравствуйте, Kvazimodo75, Вы писали:
K>Здравствуйте, Sinclair, Вы писали:
S>>1. План — от какого-то совсем другого запроса. В кроме count() есть много всего прочего, что влияет на стоимость. S>>2. Удивительным образом, на плане прямо написан совет, как ускорить ваш запрос. S>>Вы пробовали этот совет применить?
K>Данные в этой таблице постоянно обновляются, поэтому я не добавляю индексы в неё специально.
Ну знаете, тогда не стоит жаловаться. У вас идет сканирование таблицы (тупой перебор строки за строкой), потому что индексов нет. И как написал SQL Server, запрос можно улучшить в разы, добавив его.
Как по-вашему работают высоконагруженные системы с миллиардами записей — все часами ждут ответа? Думаете, там тоже без индексов совсем, потому что вставки по 1000 транзакций в минуту? Почитайте про FILLFACTOR, чтобы улучшить понимание того, что можно сбалансировать индексы, чтобы они нормально работали и на вставку, и на чтение.
Здравствуйте, Kvazimodo75, Вы писали:
K>Данные в этой таблице постоянно обновляются, поэтому я не добавляю индексы в неё специально.
Ну, я бы всё таки рискнул и посмотрел, насколько это ухудшит производительность вставки.
K>Решил тем, что результат count удивительным образом совпадает с порциями изменяемых данных, поэтому подсчитывается триггером и пишется в отдельную таблицу.
Вы и вправду думаете, что триггер с записью в отдельную таблицу будет значительно быстрее, чем обновление индекса? Почему?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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."
