Timeline for How would you identify slow queries before reaching production?
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 18, 2024 at 17:17 | comment | added | Martin Smith | SQL Server doesn't cache execution plans for views at all. It caches execution plans for statements (which may or may not reference a view) - i.e. if you have a view CREATE VIEW V1 AS SELECT C1, C2 FROM T then there is no meaningful distinction in plan caching behaviour between SELECT C1, C2 FROM T and SELECT * FROM V1 | |
| Jan 18, 2024 at 12:58 | comment | added | krillgar | @Steve Removed that section. | |
| Jan 18, 2024 at 12:57 | history | edited | krillgar | CC BY-SA 4.0 | Removing something people objected to. |
| Jan 18, 2024 at 4:31 | comment | added | Steve | "the last piece of advice I would recommend would be to use NO LOCK on your SELECT queries ... you won't be preventing other reads or writes while you get what you need" - absolute codswallop and utterly dangerous advice. Not only do reads not typically block other reads, and not only does so-called NOLOCK still involve some locking (including so-called "latching"), but there is almost no case where reading data at that isolation level is desirable. | |
| Jan 17, 2024 at 17:20 | history | answered | krillgar | CC BY-SA 4.0 |