ten query tuning techniques - amazon s3 - ten query... · the "kitchen sink" procedure...

Post on 23-May-2020

8 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

TEN QUERY TUNING

TECHNIQUES

Every SQL Programmer Should Know

Kevin Kline

Director of Engineering Services at SentryOne

Microsoft MVP since 2003

Facebook, LinkedIn, Twitter at KEKLINE

kkline@sentryone.com

Tuning blog: http://www.sqlperformance.com/

E-mail ebooks@sqlsentry.com for free copies of our e-books:

Agenda

• Introductions

• Test & tuning environment – 1. Clearing caches

• Looking for red flags – 2. Reading execution plans

• Query tuning techniques: – 10 more specific examples of widespread approaches that lead to poor performance

• Summary

3

A Reliable Test Harness

• Code to clear the caches*: – CHECKPOINT

– DBCC [FreeProcCache | FreeSystemCache | FlushProcInDB(<dbid>) ]

– DBCC DropCleanBuffers

• Code to set measurements: – SET STATISTICS [TIME | IO]

– SET SHOWPLAN [TEXT | XML] or Graphic Execution Plans

Mimicking production

• Your dev machine is usually nothing like

production – Build a stats-only database when you can (a.k.a. a database clone)

– Build representative data when you can

– Simulate equivalent hardware: DBCC OPTIMIZER_WHATIF

Red Flags in your SQL Code

• Red Flags Plan Operators: – Lookups, Scans, Spools, Parallelism Operations

• Other Red Flags: – Dissimilar estimated versus actual row counts

– High physical reads

– Missing statistics alarms

– Large sort operations

– Implicit data type conversions

1. “Good” Cursors?

• I don’t always use cursors… – …but when I do, I avoid the default options

– Slow and heavy-handed: Global, updateable, dynamic, scrollable

– I use LOCAL FAST_FORWARD

– May want to test STATIC vs. DYNAMIC, when tempdb is a bottleneck

• Blog post: http://bit.ly/AB-cursors

• DEMO

2. WHERE IN versus WHERE

EXISTS • There are lots of ways to find data existing within

subsets: – IN, EXISTS, JOIN, Apply, subquery

• Which technique is best?

• Blog post: http://bit.ly/AB-NOTIN

3. Optimizing For SELECT versus

DML (Insert, update, & Delete) • Big differences between a SELECT and a DML

statement that effects the same rows.

• Shouldn’t blindly create every index the Tuning

Advisor or execution plan tells you to!

• Blog post - http://bit.ly/AB-BlindIndex

4. Sargs: Reads & Index Structure • 8K pages

• Leaf pages ARE the data.

• Non-leaf pages are pointers.

Leaf Pages

Root Page

Level 0

Intermediate Pages

Level 1

Level 2

Writes & Index Structure • Each change to the leaf

pages requires all index

structures be updated.

Leaf Pages

Root Page

Level 0

Intermediate Pages

Level 1

Level 2

Page Split

DML

Actual place- ment

5. Unwanted Recompiles

Execution

Load metadata NO In Memory?

compile

optimize

Execute

YES

ReComp

Execute

CODE RecompileS WHEN…

• Expected: Because we request it: – CREATE PROC … WITH RECOMPILE or EXEC myproc … WITH RECOMPILE

– SP_RECOMPILE foo

– Expected: Plan was aged out of memory

• Unexpected: Interleaved DDL and DML

• Unexpected: Big changes since last execution: – Schema changes to objects in underlying code

– New/updated index statistics

– Sp_configure

EXAMPLE: Interleaved DDL and

DML • CREATE PROC testddldml AS … ;

• CREATE TABLE #testdml; -- (DDL)

• <some T-SQL code here>

• INSERT INTO #testdml; -- (DML + RECOMPILE)

• <some T-SQL code here>

• ALTER TABLE #testdml; -- (DDL)

• <some T-SQL code here>

• INSERT INTO #testdml; -- (DML + RECOMPILE)

• <some T-SQL code here>

• DROP TABLE #testdml; -- (DDL)

• <some T-SQL code here>

6. The "kitchen sink" procedure • Usually see it as a one-query-for-all-queries procedure, or even

one-proc-for-for-all-transactions procedure: – Where name starts with S, or placed an order this year, or lives in Texas

– Insert AND Update AND Delete AND Select

• Conflicting optional parameters make optimization impossible – OPTION (RECOMPILE)

– Dynamic SQL + Optimize for ad hoc workloads

– Specialized procedures

• Better approach? – Specialize and optimize each piece of code to do ONE THING really effectively

7. sp_executesql vs. EXEC(…)

• I don’t always use dynamic SQL… – …but when I do, I always use sp_executesql

– Less fuss with concatenation and implicit/explicit conversions

– Better protection against SQL injection (but not for all things)

– At worst case, behavior is the same

• Can promote better plan re-use

• Encourages strongly typed parameters instead of building up a massive string.

• Helps prevent SQL injection.

8. Implicit Conversions • SQL Server has to do a lot of extra work / scans when conversion

operations are assumed by the SQL programmer.

• Happens all the time with data types you’d think wouldn’t need it,

e.g. between date types and character types.

• Very useful data type conversion chart at http://bit.ly/15bDRRA.

• Data type precedence call also have an impact:

http://bit.ly/13Zio1f.

Implicit conversion resources • Ian Stirk’s Column Mismatch Utility at

http://www.sqlservercentral.com/articles/Administration/65138/.

• Jonathan Kehayias’ plan cache analyzer at http://sqlblog.com/blogs/jonathan_kehayias/archive/2010/01/08/finding-implicit-column-conversions-in-the-plan-cache.aspx.

• Jonathan Kehayias’ index scan study at http://www.sqlperformance.com/2013/04/t-sql-queries/implicit-conversion-costs

9. Temporary structures • Which are better, temp tables or temp

variables? Temp Table Temp Variable

Stored in? Tempdb Tempdb

Statistics? Yes No (1 row)

Indexs/Keys? Yes 1 UK / PK only

Truncate? Yes No

Recompiles? Yes No

Parallelism? Yes No

Metadata Overhead? Low Lowest

Lock Overhead? Normal Lowest

10. Coding standards and

Dissimilarity • Might sound frivolous, but standards and naming schemes are

important! – Convention is not important; but rather being consistent and logical

• Story: dbo.UpdateCustomer vs. dbo.Customer_Update

• Always specify schema when creating, altering, referencing

objects – Object resolution works a little bit harder without it

– More importantly, it can get the wrong answer

– And will often yield multiple copies of the same plan

• Do not use the sp_ prefix on stored procedures – This has observable overhead, no matter how specific you are

A Final Test

dbo stuff

dbo.test

Kev stuff

Kev.test

select * from test

dbo.sptest

(Kev) Exec sptest

SUMMARY

Let’s connect!

Facebook, LinkedIn, Twitter

at KEKLINE.

Email at

KEKline@sqlsentry.com

Blogs at

http://KevinEKline.com

Thank you! • Join me tomorrow for two more sessions of the SSWUG

vConference!

• Slides and scripts at http://slideshare.net/kkline84 and on

here.

top related