|
сервер не желает использовать фильтрованный индекс
|
|||
---|---|---|---|
#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?fid=46&gotonew=1&tid=1685501]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
26ms |
get topic data: |
9ms |
get first new msg: |
6ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
others: | 287ms |
total: | 400ms |
0 / 0 |