|
Индексы и снижение производительности
|
|||
---|---|---|---|
#18+
В каких случаях форсированное применение индекса с помощью хинта может привести к снижению производительности всей БД? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2020, 11:12 |
|
Индексы и снижение производительности
|
|||
---|---|---|---|
#18+
Interloper В каких случаях форсированное применение индекса с помощью хинта может привести к снижению производительности всей БД? Например, скан большого индекса, вместо поиска по ключу(index-seek). ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2020, 11:15 |
|
Индексы и снижение производительности
|
|||
---|---|---|---|
#18+
В тех, когда он не подходит для конкретного запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2020, 11:15 |
|
Индексы и снижение производительности
|
|||
---|---|---|---|
#18+
В моем случае есть SPA-приложение, на странице есть множество фильтров. Я заметил, что при определенном сочетании фильтров запрос медленно работает. Я сделал индекс по 3 полям, которые используются в фильтре. Сам запрос достаточно сложный из-за сортировки и пагинации, SQL Server почему-то не захотел автоматически подхватывать этот индекс - планировщик говорит, что лучше без него. Так как запрос все равно генерится динамически, я анализирую условия фильтрации и, если они подходят, форсирую индекс хинтом. И действительно, запрос по нужному фильтру стал выполняться быстро. Но, выкатив это дело на прод, увидели, что БД стала работать медленнее в целом, даже в тех запросах, которые не связаны с затронутой таблицей. Пытаюсь понять, как так вышло и как точно установить, что виновата данная оптимизация. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2020, 11:22 |
|
Индексы и снижение производительности
|
|||
---|---|---|---|
#18+
Interloper, >> даже в тех запросах, которые не связаны с затронутой таблицей значит не ней проблема ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2020, 11:26 |
|
Индексы и снижение производительности
|
|||
---|---|---|---|
#18+
Interloper В моем случае есть SPA-приложение, на странице есть множество фильтров. Я заметил, что при определенном сочетании фильтров запрос медленно работает. Я сделал индекс по 3 полям, которые используются в фильтре. Сам запрос достаточно сложный из-за сортировки и пагинации, SQL Server почему-то не захотел автоматически подхватывать этот индекс - планировщик говорит, что лучше без него. Так как запрос все равно генерится динамически, я анализирую условия фильтрации и, если они подходят, форсирую индекс хинтом. И действительно, запрос по нужному фильтру стал выполняться быстро. Но, выкатив это дело на прод, увидели, что БД стала работать медленнее в целом, даже в тех запросах, которые не связаны с затронутой таблицей. Пытаюсь понять, как так вышло и как точно установить, что виновата данная оптимизация. Ситуация вполне стандартная и распространенная. Есть большая таблица или даже комплекс таблиц и надо организовать поисковую систему. Со временем это обрастает кучей индексов и вы получаете "форсированное применение индекса с помощью хинта может привести к снижению производительности всей БД". Делаются попытки подкрутить все это, ибо перерабатывать лень, дорого, бизнес не понимает зачем, "итак все работало" и т.д. Решения такие 1) Подготовить структуру данных специально ориентированную на поиск, где данные уложены в другом виде и позволяют быстро получать то, что надо. Например, таблицы предварительной сортировки или фильтрации. 2) Вместо конгломерата индексов использовать колумнстор (не всегда, но во многих случаях помогает) 3) Воспользоваться специализированным поисковым движком, типа Elasticsearch (или кто-то может посоветовать что-то другое) 4) Применить кеширование поисковых результатов ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2020, 12:12 |
|
Индексы и снижение производительности
|
|||
---|---|---|---|
#18+
Interloper, Если вы вынуждены строить большое количество индексов по одной таблице, значит что-то не так с таблицей, надо рассматривать возможность нормализации данных этой таблицы с использование методов рефакторинга (о чем написано достаточно литературы). Если же эта таблица используется и как витрина и как средство хранения данных одновременно, то функциональность можно разделить - данные для обработки отдельно, витрина отдельно. Организовать сбор витрины, настроить индексы, для витрины их может быть много, а рабочие таблицы максимально облегчить от индексов. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2020, 15:02 |
|
Индексы и снижение производительности
|
|||
---|---|---|---|
#18+
Interloper В каких случаях форсированное применение индекса с помощью хинта может привести к снижению производительности всей БД? Или быстрее стало работать на том наборе данных, с которым тестировали, но этот набор оказался неполным, не отражающим запросы на проде. Interloper как точно установить, что виновата данная оптимизация. Ещё можно попереключать туда-сюда - а то, может, вы ещё что то поменяли, люди иногда при отладке меняют что то пачками, а потом додумывают, какое из изменений привело к результату. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2020, 19:11 |
|
Индексы и снижение производительности
|
|||
---|---|---|---|
#18+
Interloper Но, выкатив это дело на прод, увидели, что БД стала работать медленнее в целом, даже в тех запросах, которые не связаны с затронутой таблицей. Столкнулся с такой же ситуацией. Теперь на тесте и проде у меня разные индексы на разных таблицах. Просто принял как данность. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2020, 10:57 |
|
Индексы и снижение производительности
|
|||
---|---|---|---|
#18+
alexeyvg Interloper В каких случаях форсированное применение индекса с помощью хинта может привести к снижению производительности всей БД? Или быстрее стало работать на том наборе данных, с которым тестировали, но этот набор оказался неполным, не отражающим запросы на проде. Или прода и тест настроены по-разному. MSSQLSERVER, я имею ввиду. Например, может очень сильно влиять разница в collations. Фатально, я б сказал. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2020, 12:54 |
|
|
start [/forum/topic.php?fid=46&msg=39940355&tid=1686297]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
41ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
others: | 317ms |
total: | 454ms |
0 / 0 |