Timeline for Is it a parameter sniffing problem?
Current License: CC BY-SA 4.0
8 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jul 11, 2018 at 3:50 | vote | accept | Jay Chen | ||
Jun 27, 2018 at 14:09 | comment | added | pacreely | @JayChen don't change it, your variable and column should be the same type to prevent implicit conversions. | |
Jun 27, 2018 at 13:16 | comment | added | Jay Chen | @pacreely yes, it is a NVARCHAR type, should I change it to varchar? (unicode is not required for this column) Hi Aaron, Thanks, I will try and see how | |
Jun 27, 2018 at 12:33 | comment | added | Aaron Bertrand | @JayChen Don’t put a lot of weight into the estimated cost % shown in an estimated plan. They can occasionally be useful guide posts but if you’re just looking at a single plan what is the value? Every query is going to have costs that add up to 100% of the cost. Run the query and see if it is faster. | |
Jun 27, 2018 at 12:26 | comment | added | pacreely | @JayChen a 'clustered index seek' is not a bad thing, it's way better than a 'table scan'. The only additional overhead is on the update, it's worth testing the query to get the actual IO and TIME. A half-way option would be to keep the table as a Heap and create a Non-Clustered index on staffid. You'll be able to perform RID lookups and have less update overhead. Also, is the staffid column an NVARCHAR? | |
Jun 27, 2018 at 11:48 | comment | added | Jay Chen | Hi pacreely, yes, my table does not have an index on StaffID. I have tried to index StaffID column and checked the execution plan, it seems the costing is worse than before, as it needs to do the 'clustered index update' (304%) and 'clustered index seek' (100%) AIK, indexing will slow down the update statement, is it a correct way to solve this problem? | |
Jun 27, 2018 at 10:30 | comment | added | Tibor Karaszi | Good point about the index. Definitely check if there is an index on StaffID! | |
Jun 27, 2018 at 9:15 | history | answered | pacreely | CC BY-SA 4.0 |