What you need to be aware of is: this operator is on the outer (lower) input of a Nested Loops join operator.
You’ll see the same values as above (after all the properties shown on an arrow are by definition a subset of the properties of the right-hand side operator of that arrow), but you’ll see many other properties too. Let’s also look at the properties of the Clustered Index Seek itself. That looks like a terrible estimate, and many people would jump right in to investigate.īut in reality, this is just SQL Server being deliberately confusing. The Clustered Index Seek is estimated to return 3.86 rows, yet it actually returns 245 rows. If you look at this, you’ll see a big giant red flag. And included in the screenshot is the property popup you get when you hover your mouse over the arrow between the Clustered Index Seek and the Nested Loops: Here’s the execution plan you should see. Just execute this query against any AdventureWorks database, and request an execution plan plus run-time statistics (formerly known as actual execution plan): SELECT sod.SalesOrderID, If you have been to any of my talks about execution plan, you probably have heard me fuming about (and warning you for) the way estimated and actual number of rows are shown in execution plans.īut for those that haven’t met me yet, here is a short explanation. One I wish Microsoft had done … oh, let’s say two decades ago? Misleading information Why the rush, you ask? Because hidden in between all the little (and some big) improvements and fixes, there is one true gem.
#Download sql server management studio 18.5 update
Version 18.5.Īnd I need all of you to update your version. The latest version of SSMS has just been released.