Geek Sync | Why Did My Clever Index Change Backfire?
Download as PPTX, PDF0 likes202 views
The document discusses common blunders associated with filtered indexes and indexed views in SQL Server, highlighting the challenges of creation, maintenance, and performance. It emphasizes the importance of thorough testing and careful management of index cleanup to avoid deadlocks and performance issues. The author also suggests best practices for avoiding these blunders, including testing data modifications and capturing query plans before making changes.
![We need to support a new
aggregate query
• Table with hundreds of millions of rows
• Can have rapid inserts
• Simple query with one join
• Groups by YEAR([DATETIME2 column])](https://image.slidesharecdn.com/sqlworkbookswhydidmycleverindexchangebackfire-20180321-180321165116/85/Geek-Sync-Why-Did-My-Clever-Index-Change-Backfire-13-320.jpg)
Geek Sync | Why Did My Clever Index Change Backfire?
- 1. Why Did My Clever Index Change Backfire? Kendra Little March 21, 2018
- 2. Hi, I’m Kendra Little • Path: Database Administrator, Consultant, Trainer • Microsoft Certified Master • Founder of SQLWorkbooks.com @Kendra_Little
- 4. Today’s blunders Index cleanup accident Frustrating filtered index Ugly indexed view Anti-blunder patterns 3 1 2 4
- 6. A new process: ‘flagging’ • Table with hundreds of millions of rows • Can have rapid inserts • Small percentage of rows flagged for review • After a row is reviewed, the flag is cleared
- 7. Sounds like a filtered index! • Very selective • Simple one-column predicate (no functions or computed columns needed) • Must update dynamically We’ve used filtered indexes before What could go wrong?
- 8. Demo: The filtered index that literally couldn’t even
- 9. Ouch! I wish I’d discovered that BEFORE deploying to production
- 10. SET OPTIONS that affect results https://technet.microsoft.com/en-us/library/ms175088.aspx
- 11. Blunders with filtered indexes 1. Can you create the filtered index? • If the table was created with the wrong settings, you can’t even create it 2. Will your code use the filtered index? • “Unsafe” parameterization 3. Do inserts, updates, & deletes from the app work? • Also test for indexed views and persisted computed columns
- 12. The ugly indexed view
- 13. We need to support a new aggregate query • Table with hundreds of millions of rows • Can have rapid inserts • Simple query with one join • Groups by YEAR([DATETIME2 column])
- 14. Sounds like a case for an indexed view! • Groups by a defined column • Must update dynamically We’ve used indexed views before… But not on these tables
- 15. Demo: the ugly indexed view
- 16. The foreign key only helps in the case of inserts • If we allow updates to FirstName in ref.FirstName, it is going to have to update the indexed view • That will be slow unless we add a nonclustered index on dbo.FirstNameByBirthDate to make finding related rows fast
- 17. Well… at least the insert sorta worked this time?
- 18. Top blunders with indexed views 1. Problems with ‘SET’ options (like filtered indexes) 2. May be required to use NOEXPAND in code, even with Enterprise Edition 3. INSERT, UPDATE, and DELETE statements may need supporting nonclustered indexes on the base tables for performance if foreign keys don’t “cover” checking for related rows
- 20. We’re cleaning up indexes We know that unneeded indexes waste resources – Disk – Memory (even pure duplicates may be read) – Index maintenance time/perf – CHECKDB time / perf – Backup time / space, – Overhead for data modifications We’re going to clean up some duplicates
- 21. Demo: index cleanup accident
- 22. Not again!
- 23. What happened? SQL Server only needs to lock an index if the column being modified is in the index The “near-duplicate” nonclustered index happened to be a safe path for the select query Removing that path allowed the deadlock to happen
- 24. Blunders with index cleanup • Queries will fail if they hint an index which does not exist • Index changes can cause deadlocks (including seemingly innocent index cleanup changes)
- 26. Avoiding blunders 1. Test data modifications 2. Clean up indexes in batches 3. Capture top queries with plans before the change
- 27. 1. Test data modifications Test from the calling application – Testing from SSMS isn’t enough – Don’t skip the small tables The “fancier” your indexes are, the more critical this becomes
- 28. 2. Clean up indexes in batches Prioritize and group index cleanup – The more critical the database, the slower you should go – Handle the biggest opportunities first – Search for indexes hinted by name in the codebase – Look out for deadlocks after index changes – Document any indexes added to prevent deadlocks in the source code
- 29. 3. Capture top queries It’s possible to hit a performance regression with any change Handling it afterward is much easier if you know what the plan was like before!
- 30. Make a rollback plan (and test it!)
Editor's Notes
- #4: I’ve lived through this so many times
- #7: Filtered indexes introduced in sql server 2008.
- #11: CX is ~3.3GB, ~146.5 million rows.
- #13: This takes 10 seconds
- #45: Even in Enterprise Edition
- #68: Imagine that we have a procedure like this-- except it'd be smart enough to handle when zero rows are modified, error handling, etc.
- #71: The second query is blocked