|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
имеется здоровенная таблица с вот таким индексом: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
в принципе он подходит, но он тоже большой, хоть и компресснутый. а EF долбит сервер вот таким вот шедевром: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
создаю ему вот такой индекс: Код: sql 1. 2. 3. 4.
он крошечный, но сервер его не берет. прописываю его хинтом, он тогда использует, но лезет в ПК за IdVeicolo. что вообще-то против всякой логики: если он не верит, что [IdVeicolo] IS NULL, то не должен пользоваться этим индексом вообще, должен кричать, что план из-за хинта создать не может. а раз может, то чего лезет в ПК? но черт с ним, я ему добавляю IdVeicolo в инклуд. не, не берет все равно. хинтом прописываю, в ПК уже не лезет, запрос выполняется быстрее, чем если брать нефильтрованный индекс, но ведь не берет и все, да еще и несусветную стоимость птиписывает хинтованному запросу. вопрос: почему? прилагаю планы актуальные. первый с указанным фильтрованным индексом, второй с переделанным индексом, вот таким: Код: sql 1. 2. 3. 4.
plan1 plan2 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 17:19 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
Не вникал в планы, но, по всей видимости, проблема тут Код: sql 1.
Добавьте это поле в inclued секцию. Без этого фильтрованный индекс на is null не работает. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 17:24 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
msLex Не вникал в планы, но, по всей видимости, проблема тут Код: sql 1.
Добавьте это поле в inclued секцию. Без этого фильтрованный индекс на is null не работает. Опс, это вы уже сделали, но без хинта индекс не используется Тогда нужно смотреть планы. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 17:27 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
так вот, второй план показывает, как он не желает брать переделанный индекс, в который как раз и добавлено IdVeicolo: Код: sql 1. 2. 3. 4.
не берет, и стоимость ему насчитывает офигенную ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 17:29 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
мб Код: sql 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 17:29 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
msLex Тогда нужно смотреть планы. планы не лезут без архивации, у меня ссылки на брентозаровскую вставлялку планов ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 17:30 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
istrebitel мб Код: sql 1. 2. 3. 4.
и этот тоже не берет, хотя уже считает, что стоимость 50х50 plan3 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 17:35 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
А что за [FLEETXS].[dbo].[Transazioni].[ix_fltr_datainserimento]? Он почему-то попал в unmatched indexes ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 17:41 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
msLex А что за [FLEETXS].[dbo].[Transazioni].[ix_fltr_datainserimento]? Он почему-то попал в unmatched indexes ну есть такой, да, только совсем не под этот запрос: Код: sql 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 17:43 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
и да, надо в него тоже в инклуд IdDispositivo воткнуть, его он тоже не брал добровольно и он у меня хинтом прописан. там все же sp, а не сгенеренный бред от EF ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 17:46 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
Yasha123, покажите определение кластерного индекса еще и желательно гистограмму колонок Id и IdCliente вообще там же еще переменная он может с вектор плотности вместо гистограммы использовать. можете как то к запросу вкорячить option (recompile) или optimize for (@p__linq__0 = const) ? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 17:57 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
Совсем не понятно, что за дичь происходит перед index seek в первом запросе второго плана. Ведь выбираемый индекс просто идеально подходит под запрос, и должен быт 1 index seek (что и ожидает сервер), а по факту происходит 2(!). Может где с типами параметров и полей несоответствие? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 18:03 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
msLex Совсем не понятно, что за дичь происходит перед index seek в первом запросе второго плана. Ведь выбираемый индекс просто идеально подходит под запрос, и должен быт 1 index seek (что и ожидает сервер), а по факту происходит 2(!). Может где с типами параметров и полей несоответствие? Так, стало понятней Он вот эту портянку в NOT( ... in) пытается преобразовать в интервалы, а их использовать для более точного index seek по всем 4-м полям индекса. а вот этот тот первый индекс конкретно по этот запрос сделан? можно ли для эксперимента убрать из ключа (перенеся в include) последнее поле? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 18:15 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
Yasha123, еще интересно проверить что будет если ему побольше время дать на подсчет плана, сколько он будет подбирать что бы ушло StatementOptmEarlyAbortReason="GoodEnoughPlanFound" если можете проэкспериментировать с каким нибудь тестом (querytraceon 8780 querytraceon 8671) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 18:28 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
msLex а вот этот тот первый индекс конкретно по этот запрос сделан? можно ли для эксперимента убрать из ключа (перенеся в include) последнее поле? первый индекс не только под этот запрос, там еще StatusFatturazione, помониторю еще в день Fatturazione, это будет 8-ого числа, а так у меня руки чешутся дропнуть первый индекс, на данный момент его только этот запрос использует. хотим перенести Tipo в инклуд? сейчас сделаю на копии базы. кстати, если наоборот во втором индексе занести Tipo в ключ, то все равно не берет, хотя и насчитывает ему меньшую стоимость (52 x 48) plan4 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 18:29 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
felix_ff Yasha123, покажите определение кластерного индекса еще и желательно гистограмму колонок Id и IdCliente вообще там же еще переменная он может с вектор плотности вместо гистограммы использовать. можете как то к запросу вкорячить option (recompile) или optimize for (@p__linq__0 = const) ? кластеред там тупее некуда, Код: sql 1. 2. 3. 4.
(id int identity) вкорячить туда recompile не выйдет, это генерит EF, но если это в студии вкорячить, результат не меняется, уже проверено ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 18:36 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
Yasha123 хотим перенести Tipo в инклуд? сейчас сделаю на копии базы. Да, это должно отбить охоту от построения этих ненужных интервалов. В этом случае скорость работы с первым индексом должна сравнятся со вторым (это при прочих равных типа FG, кеширование и т.п.) Yasha123 кстати, если наоборот во втором индексе занести Tipo в ключ, Это приводит к такому-же плану, что и в исходном варианте, т.е. скорость выполнения должна упасть. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 18:38 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
Первоначально seek predicates для запроса с обычным индексом гораздо точнее, чем для запроса с фильтрованным. Как раз за счет tipo в ключе индекса и применения "ненужного" merge interval. Это видно по значениям Estimated Number of Rows to be Read в планах. Отсюда и бОльшая стоимость запроса с фильтрованным. Поэтому показано добавление IdDispositivo и tipo в ключ фильтрованного. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 18:48 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
вот план при индексах: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
plan5 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 18:49 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
invm Поэтому показано добавление IdDispositivo и tipo в ключ фильтрованного. IdDispositivo в ключе полностью нивелируется IdDispositivo = 0 в условиях фильтрованного индекса а интервалы фильтрации по tipo для условия Код: sql 1.
выглядят просто сюром. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 18:56 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
felix_ff Yasha123, еще интересно проверить что будет если ему побольше время дать на подсчет плана, сколько он будет подбирать что бы ушло StatementOptmEarlyAbortReason="GoodEnoughPlanFound" если можете проэкспериментировать с каким нибудь тестом (querytraceon 8780 querytraceon 8671) мне кажется, времени ему хватает, но вот план с флагами: plan6 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 19:01 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
граждане, у меня уже крыша едет, объясните мне, зачем это EF приводит значения к типу bigint, когда в таблице поле Tipo это int? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 19:09 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
msLex а интервалы фильтрации по tipo для условия Код: sql 1.
выглядят просто сюром. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 19:10 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
Yasha123 а у вас для модели EF структура ссылающаяся на таблицу не определена случаем как long? а интервалы фильтрации по tipo для условия AND ( NOT ( CAST( [Extent1].[Tipo] AS bigint) IN (cast(7 as bigint), cast(15 as bigint), cast(16 as bigint), cast(17 as bigint), cast(18 as bigint), cast(19 as bigint)))) выглядят просто сюром. там же предикат на неравеноство, он для этого отрезки и составляет ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 19:17 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
felix_ff а у вас для модели EF структура ссылающаяся на таблицу не определена случаем как long? да кто их знает. я не трогаю их код, а им сказано не трогать серверный. попробую спросить, но уже в понедельник. думаю, никто даже не пошевелится. что работает, к тому не прикасаются --- а скажите, плиз, в их терминах, как надо переопределить? попробую начальство загрузить, сразу нужный тип указав ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 19:29 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
invm msLex а интервалы фильтрации по tipo для условия Код: sql 1.
выглядят просто сюром. типов у нас ровно 90, если что. но начальник ссыкается, вдруг типа int не хватит, поэтому под угрозой расстрела во всех таблицах требует id bigint. с типом они когда-то облажались, да, а теперь слишком много всего переделывать, так и оставили. но видимо в модели считается, что всюду bigint. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 19:40 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
Yasha123, у них будет построена модель в виде класса c кучей свойст каждое из которых отмаплено по сути на отдельную колонку таблицы Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
вот в случае если у них тип поля для Tipe объявлен в модели как long тогда при отправке запроса EF будет формировать SQL запрос приводящий значения к типу bigint судя по самому SQL запросу у вас в EF модели код вида или что то подобное: Код: c# 1. 2. 3. 4.
меня еще если честно смущает что сервер во всех планах промахивается достаточно сильно в оценке строк по предикатам ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 19:40 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
invm msLex а интервалы фильтрации по tipo для условия Код: sql 1.
выглядят просто сюром. Если уникальных типов 100500 то лучше 1 раза просканировать весь дипазон, чем два почти полных скана (<15) (>19) я понимаю, если бы условия был на in, но там же not in ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 19:45 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
вот как раз все остальные id типа IdVeicolo, IdCliente они все bigint. так что там наверное везде long, и для типа они скопировали, потому что копипаст наше все. значит, надо переделать на int? так называется сиквельный int в их модели? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 19:45 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
Yasha123 значит, надо переделать на int? так называется сиквельный int в их модели? да, но это уберет просто cast'ы не думаю что проблема именно в них ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 19:48 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
felix_ff Yasha123 значит, надо переделать на int? так называется сиквельный int в их модели? да, но это уберет просто cast'ы не думаю что проблема именно в них спасибо, в понедельник скажу, что 2019-ый сервер не любит неправильные типы и что им это аукнется. должно прокатить. переехали на 2019 недавно, месяца не прошло, сюрпризов туча, скажу, сервер не хочет их long, пускай переделывают ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 19:51 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
Yasha123, погодите, а если вы в студии выполняете Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
он фильтрованный индекс подхватывает? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 19:54 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
Yasha123 переехали на 2019 недавно, месяца не прошло, сюрпризов туча, слышал недавно в подкасте: Брент открещивается от 2019 и говорит переходить на него, только если по-другому никак ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 20:05 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
да нет же. у меня все планы из студии и есть. уже сделан индекс, где все поля в ключе, но со все тем же фильтром, и все равно не берет, хотя сам же ему дает меньшую стоимость. но и не из студии не берет тоже, я же смотрю статистику использования индексов, не берет его вообще, только с моими пинками. в их запросе никакое не declare, там параметр (имя сохранено) генерит его EF. и думаю, что все клиенты через это проходят. а план один на всех, он у меня вылез в запросе на использование того индекса, который хочу дропнуть. остальные запросы, где #tra, это sp. с этим я разберусь ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 20:06 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
to komrad Брент есть мерзкий тип, мы пересекались на стэке, наглая самодовольная свинья. да достаточно комментарии к его статьям почитать, пока не зачистил неугодное. а с 2019 вообще полный трэш: хозяин барака решил какой-то там сертификат получить, ему понадобился TDE. а это только Энтерпрайз. у них был 2012 Стандард, и решили они сразу перейти на 2019 Энтерпрайз. говорю, может хоть 2016, хоть сп уже вышли? не-не, хотим 2019 и все тут. мигрировали вообще без тестирования приложения. огребаем. разгребаем. под шумок попробуем избавиться от long. в целом всплыло только дерьмо, полное OR. ну так его давно пора было переписать. теперь я им тоже говорю: кто напишет мне тучу OR, тому расстрел, сервер это найдет в 2 счета. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 20:15 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
felix_ff Yasha123, погодите, а если вы в студии выполняете Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
он фильтрованный индекс подхватывает? аааа, пардон, без приведения типов ? не, все равно не берет. и еще и предлагает создать индекс, какой у меня и так сделан, только без фильтра. это называется ССЗБ ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 20:24 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
Yasha123, в том то и дело приведение к bigint мало влияет на выбор плана в данном случае. а если попробовать сократить варианты интервала что бы он не строил merge interval скажем попробовав построить план для такого варианта: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
тоже не возьмет индекс? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 21:21 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
felix_ff Yasha123, в том то и дело приведение к bigint мало влияет на выбор плана в данном случае. а если попробовать сократить варианты интервала что бы он не строил merge interval скажем попробовав построить план для такого варианта: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
тоже не возьмет индекс? Думаю, что нет. Исходный индекс достаточно хорош для запроса. фильтрованный ничем не лучше. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 21:24 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
msLex, да, согласен не успел написать. поведение моделируется: Код: 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. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67.
в первом запросе выбирает [ix_IdVeicolo_IdCliente_Disabilitato_Tipo_incl] это конечно "грубый тест", нет гистограмм по колонкам. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
add: хотя не, тест так себе поскольку для первого запроса он у меня не видит нормального кол-ва строк, походу статистики реально не хватает, гистограммы бы подтянуть :( ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 21:35 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
msLex чем два почти полных скана (<15) (>19) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 21:57 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
invm msLex чем два почти полных скана (<15) (>19) Там два интервала, возвращаемые из merge interval, из-за чего index seek выполняется дважды. По условию not in понятно, что интервалы будут максимально широкими, по другому просто не может быть. А по количеству прочитанных (до predicate фильтра) данных, видно, что это дополнительный seek predicate по Tipo вообще ни чего не дает и там и там Number of Rows Read = 285439 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 22:14 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
Yasha123 Он так по дефолту делает автогенератором, разработчики не лезут туда. Я тоже не мог понять, но проще забить, некогда было разбираться. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 22:29 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
msLex Там два интервала, возвращаемые из merge interval ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2020, 10:20 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
msLex Исходный индекс достаточно хорош для запроса. фильтрованный ничем не лучше. фильтрованный лучше для меня и для процедур, меняющих данные. он значительно меньше и в нем нет в ключе idVeicolo, который мееяется. процедуры обновления данных стреляются от количества индексов на таблице. вопрос вообще чисто академический. похоже, просто заменю исходный индекс на нефильтрованный по idcliente. раньше не было возможности на лету индексы менять, чего сервер требовал, то и создавали ночью, в джобе. сейчас есть online и compression, можно все переделать и если не подошло, поменять назад не отходя от кассы. всем спасибо за участие, вчера же вечером фильтрованные индексы с условием is null получили налловое поле в иклуд и процедуры избавились от хинтов, так что мы с сервером вас благодарим :) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2020, 11:02 |
|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#18+
Yasha123, надо проверить настройку базы Параметризация, если она принудительная, то фильтрованный индекс не будет использован. Если указать хинт использовать этот индекс, то будет получена ошибка. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2020, 14:09 |
|
|
start [/forum/topic.php?all=1&fid=46&tid=1685501]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
29ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
others: | 275ms |
total: | 414ms |
0 / 0 |