Proving Views Can Hurt Performance
Content rating: Beginner to experienced
For some of you, this will be a "no duh" blog. But I've had this argument with people, so here we go.
Views can hurt performance. Not by their very existence, no. Not by rule, no. But in certain situations, yes. The situation is: If you're querying off of a view that's pulling much more data than you need (horizontally or vertically), and/or doing more processing than you need (outer joins, date functions, case statements), your query may have worse performance than just running it off the base tables.
As an example, I refer you to my previous blog, in which we restored Brent Ozar's Twittercache database. Get it and restore if you want to follow along.
Once you've done that, create this view in the TwitterCache database:
ALTER VIEW userTweetsHistory AS SELECT a.[text], b.[USER_ID] , c.NAME , c.screen_name , c.cached_date , B.cached_date AS HistoryCachedDate, b.followers_count FROM Statuses a JOIN UsersHistory b ON b.[user_id] = a.[user_id] LEFT OUTER JOIN Users c ON c.screen_name = b.screen_name AND CONVERT(VARCHAR(10), c.cached_date, 101) = CONVERT(VARCHAR(10), b.cached_date, 101) WHERE c.screen_name NOT LIKE 'SQL%' AND c.cached_date > '11/1/2009'
What we have here is a view…a view that no one would ever really need, but a view nonetheless. I've seen many similar in my day, so don't try to tell me I'm making this unrealistically complicated. What we want is the screen_name and cache_date for 'midnightDBA' where the follower_count is > 100. Turn on "Include Actual Execution Plan", and run these two statements together:
SELECT screen_name , HistoryCachedDate FROM userTweetsHistory WHERE screen_name = 'midnightdba' AND followers_count > 100 SELECT screen_name , cached_date FROM UsersHistory WHERE screen_name = 'midnightdba' AND followers_count > 100
The first reads from the view, the second from the base table. The first query is 78% of the batch (on my box)…it takes FOUR TIMES AS MUCH EFFORT for SQL to run the query from the view as it does the query from the base table. Again, this is because the view is doing more than we need it to do for this query.
The bottom line is NOT that views are bad, or that views hurt performance. The bottom line is that inappropriate views hurt performance.
Thanks for playing,
Jen McCown
[...] talked before about how inappropriate views hurt performance, and I will talk in the future specifically about how nested views hurt performance, but today I [...]
[...] blogs on performance, views, and nested views: Proving Views Can Hurt Performance, Detangling Nested [...]
I’m not saying that the premise of the article is wrong, but the view goes to an inner join with the where clause, so the performance measurement between the two is not equal. One will be joining tables and only returning the records that match the criteria of the second table, the other strictly goes against a single table. Depending on the cardinality of the second table you also might return more records than you would expect if you were comparing just the values in the base table to that returned from the view. Of course, that more than proves your point there… know what the view should be used for and only use it for that purpose.