Azure SQL查询编辑器vs Management Studio

Question

I'm pretty new to azure and cloud computing in general and would like to ask your help in figuring out issue.

Issue was first seen when we had webpage that time outs due to sql timeout set to (30 seconds).

First thing I did was connect to the Production database using MS SQL management studio 2014 (Connected to the azure prod db)

Ran the stored procedure being used by the low performing page but got the return less than 0 seconds. This made me confused since what could be causing the issue.

By accident i also tried to run the same query in the Azure SQL query editor and was shock that it took 29 seconds to run it.

My main question is why is there a difference between running the query in azure sql query editor vs Management studio. This is the exact same database.

DTU usage is at 98% and im thingking there is a performance issue with the stored proc but want to know first why sql editor is running the SP slower than Management studio.

Current azure db has 50 dtu's.

Answer 1

Two guesses (posting query plans will help get you an answer for situations like this):

1. SQL Server has various session-level settings. For example, there is one to determine if you should use ansi_nulls behavior (vs. the prior setting from very old versions of SQL Server). There are others for how identifiers are quoted and similar. Due to legacy reasons, some of the drivers have different default settings. These different settings can impact which query plans get chosen, in the limit. While they won't always impact performance, there is a chance that you get a scan instead of a seek on some query of interest to you.

2. The other main possible path for explaining this kind of issue is that you have a parameter sniffing difference. SQL's optimizer will peek into the parameter values used to pick a better plan (hoping that the value will represent the average use case for future parameter values). Oracle calls this bind peeking - SQL calls it parameter sniffing. Here's the post I did on this some time ago that goes through some examples: https://blogs.msdn.microsoft.com/queryoptteam/2006/03/31/i-smell-a-parameter/

I recommend you do your experiments and then look at the query store to see if there are different queries or different plans being picked. You can learn about the query store and the SSMS UI here: https://docs.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store?view=sql-server-2017

For this specific case, please note that the query store exposes those different session-level settings using "context settings". Each unique combination of context settings will show up as a different context settings id, and this will inform how query texts are interpreted. In query store parlance, the same query text can be interpreted different ways under different context settings, so two different context settings for the same query text would imply two semantically different queries.

Hope that helps - best of luck on your perf problem