Download as pdf or txt
Download as pdf or txt
You are on page 1of 23

Watch Brent Tune Indexes

Brent Ozar, MCM, MVP, BBQ, LOL


Thank You Sponsors!

Visit the Sponsor


tables to enter their
end of day raffles.

Turn in your completed Event Evaluation


form at the end of the day in the Registration
area to be entered in additional drawings.

Want more free training? Check out the


Houston Area SQL Server User Group
which meets on the 2nd Tuesday of each
month. Details at
http://houston.sqlpass.org
www.BrentOzar.com
sp_Blitz® – sp_AskBrent®
email newsletter – videos
SQL Critical Care®
BrentOzar.com
/go/tuneindexes
My index tuning strategy
Dedupe – reduce overlapping indexes

Eliminate – unused indexes

Add – desperately needed missing indexes

Tune – resource-intensive query plans

Heaps – usually need clustered indexes

BrentOzar.com/go/tuneindexes
My index tuning strategy
Dedupe – reduce overlapping indexes

Eliminate – unused indexes

Add – desperately needed missing indexes

Tune – resource-intensive query plans

Heaps – usually need clustered indexes

BrentOzar.com/go/tuneindexes
More indexes, more problems
More indexes means slower:
• Deletes/updates/inserts (DUIs)
• Index and stats maintenance jobs
• Backups and restores
• DBCC CHECKDB (and corruption repair)
• Worse concurrency if they cause blocking issues
• Contention for memory
• Startup time of in-memory OLTP databases
Dedupe redundant indexes
Our customers table has 3 different indexes:
LastName, FirstName, MiddleName
LastName, FirstName
LastName
Dedupe redundant indexes
Our customers table has 3 different indexes:
LastName, FirstName, MiddleName
LastName, FirstName
LastName

SELECT Id FROM dbo.Customers


WHERE LastName = 'Ozar'

SELECT Id FROM dbo.Customers


WHERE LastName = 'Ozar’ AND FirstName = 'Brent'
My index tuning strategy
Dedupe – reduce overlapping indexes

Eliminate – unused indexes

Add – desperately needed missing indexes

Tune – resource-intensive query plans

Heaps – usually need clustered indexes


Gotchas of eliminating indexes
SQL Server 2012 & 2014 reset usage stats when
indexes are rebuilt.
SQL Server 2016 fixes that.
Always On Availability Groups don’t centralize index
usage stats either.
The quarterly CEO report problem
My index tuning strategy
Dedupe – reduce overlapping indexes

Eliminate – unused indexes

Add – desperately needed missing indexes

Tune – resource-intensive query plans

Heaps – usually need clustered indexes


SQL Server’s missing index DMVs
Track how many queries / query plans wanted a particular
index, and roughly how much faster the query would have
been

Recommends super-wide indexes (many fields), near


duplicates

Only concerned with speeding up selects, not DUIs


My index tuning strategy
Dedupe – reduce overlapping indexes

Eliminate – unused indexes

Add – desperately needed missing indexes

Tune – resource-intensive query plans

Heaps – usually need clustered indexes


Tune query plans by hand
After letting the prior steps bake for a few weeks, look at
your most resource-intensive queries:

sp_BlitzCache @sort_order = 'reads'


sp_BlitzCache @sort_order = 'cpu'

They may have missing index recommendations,


but probably not (if you’ve done a good job so far),
so you may have to create the indexes by hand.
My index tuning strategy
Dedupe – reduce overlapping indexes

Eliminate – unused indexes

Add – desperately needed missing indexes

Tune – resource-intensive query plans

Heaps – usually need clustered indexes


Heap: a table without a clustered index.
The data is just scattered around, not in logical order.

When we don’t define a clustered index,


we’re telling SQL Server, “ah, just put it wherever.”

This is great when you want to stuff data in,


but not always great when you want to query it.
SQL Server politely ignores heaps.
SQL Server won’t recommend clustered indexes for
heaps.
It won’t suggest good non-clustered indexes either.
SQL Server doesn’t even always clean up heaps
when you delete data out of them.
The fix: add a clustered index:
Narrow
Unique
Static
Ever-increasing
Existing primary key that happens to fit,
but it’s nonclustered? Consider clustering on it.
There are rare exceptions
to the heap rule.
“I’m just loading data in, pulling it back out, then truncating.”

“I only ever insert into this, I never update or delete,


and when I select, I just scan the whole table.”

“I have done extensive A/B testing and have proved that


heaps are faster for all of the queries that access this table.”
My index tuning strategy
Dedupe – reduce overlapping indexes

Eliminate – unused indexes

Add – desperately needed missing indexes

Tune – resource-intensive query plans

Heaps – usually need clustered indexes


BrentOzar.com
/go/tuneindexes

You might also like