Timeline for Stale Statistics and View performance on SQL Server 2016
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 3, 2021 at 18:13 | history | edited | Aleksey Vitsko | CC BY-SA 4.0 |
deleted 5 characters in body
|
| Mar 17, 2021 at 9:39 | comment | added | ranit.b | Thanks @Charlieface. Yes, there were several Nested Loops. I agree with your thought on joining with skewed table(s). | |
| Mar 16, 2021 at 21:19 | comment | added | John K. N. | Please add the query execution plan via Paste the Plan. | |
| Mar 16, 2021 at 20:43 | comment | added | Charlieface |
I suspect it's more likely a join condition rather than the select itself. Do you have any unusual joins: convert/cast or other function, or perhaps one of the joins is a very skewed table?
|
|
| Mar 16, 2021 at 18:58 | answer | added | Aleksey Vitsko | timeline score: 1 | |
| Mar 16, 2021 at 17:13 | comment | added | ranit.b | 1)Just removing the ISNULL fixes slowness. 2)Didn't try w/o fullscan (but tried rebuilding indexes and that too serves the purpose) | |
| Mar 16, 2021 at 17:03 | comment | added | rois | Removing the ISNULL from the SELECT columns helps resolve the query slowness <-- does this mean removing the ISNULL only fixes the problem or when you remove those columns completely? Also: as I understand updating statistics without specifiying fullscan doesn't fix the issue? | |
| Mar 16, 2021 at 16:23 | history | edited | ranit.b | CC BY-SA 4.0 |
added 376 characters in body
|
| Mar 16, 2021 at 16:17 | history | asked | ranit.b | CC BY-SA 4.0 |