Top Tips for Better T-SQL
•
3 likes•874 views
T-SQL provides many different ways to accomplish the same task, and as you might expect, some ways are better than others. Also, it's very simple to write your T-SQL in a way that no one else can read. In this session, you will learn specific techniques, that if followed, will make you a better T-SQL developer. The session is jam-packed with practical examples and is designed for administrators and developers who want to bring their T-SQL skills to the next level. You'll write clearer and easier to read T-SQL as well as write better performing T-SQL. In fact, you will be able to immediately implement these tips in your current projects once you get back to your office.
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Top Tips for Better T-SQL
Similar to Top Tips for Better T-SQL (20)
More from Grant Fritchey
More from Grant Fritchey (20)
Recently uploaded
Recently uploaded (20)
Top Tips for Better T-SQL
- 1. Grant Fritchey | www.ScaryDBA.com www.ScaryDBA.com Top Tips for Better T-SQL Stored Procedures Grant Fritchey – Red Gate Software
- 2. Grant Fritchey | www.ScaryDBA.com Goal Learn methods for writingT-SQL for readability Understand how to write T-SQL for performance 2
- 3. Grant Fritchey | www.ScaryDBA.com Get in touch scarydba.com grant@scarydba.com @gfritchey Grant Fritchey
- 4. Grant Fritchey | www.ScaryDBA.com Agenda Writing for readability » Object Names & Format » Comments » Error Handling » Personal Preferences Writing for performance » DataTypes » Functions inComparisons » ImproperUse of Functions » The “Run Faster” Switch » InappropriateUse ofQuery Hints » Recompiles » Row byAgonizing Row » NestingViews 4
- 5. Grant Fritchey | www.ScaryDBA.com Writing for Readability Define a local standard » Object names » Comments » Format » Error handling Enforce the standard » Document it » Code reviews 5
- 6. Grant Fritchey | www.ScaryDBA.com Object Names & Format Names should be descriptive » Procedures should be a phrase » Abbreviations should be common (no Ddltbl) Use aliases » Clear » Common Be consistent » A foolish consistency is the hobgoblin of little minds » Keyword in that sentence is “foolish” 6
- 7. Grant Fritchey | www.ScaryDBA.com Comments Do something Most important is describing the action, not documentation Use source control for documentation Self-documenting code is a lie 7
- 8. Grant Fritchey | www.ScaryDBA.com Error Handling TRY/CATCH Deadlocks Establish local best practices 8
- 9. Grant Fritchey | www.ScaryDBA.com Personal Preferences CamelCase Uppercase for reserve words and key words Line breaks » On SELECT list » Between JOIN criteria » BetweenWHERE criteria Use the semicolon Indent » After initial SELECT » With ON clause » AfterWHERE clause 9
- 10. Grant Fritchey | www.ScaryDBA.com Writing For Performance Write for your data structures Write for your indexes Write for the query optimizer Avoid common issues: » Data types » Functions in comparisons » Improper use of functions » The “run faster” switch » Inappropriate Query Hints » Recompiles » NullValues » Row By Agonizing Row » NestedViews 10
- 11. Grant Fritchey | www.ScaryDBA.com Data Types Problem » Implicit or explicit data type conversion Indications » Scans » Slow performance Solution » Use appropriate data types 11
- 12. Grant Fritchey | www.ScaryDBA.com Functions in Comparisons Problem » Function on column in WHERE or JOIN criteria Indications » Scans » Slow performance Solution » Don’t run functions on columns » Use sargeable functions 12
- 13. Grant Fritchey | www.ScaryDBA.com Improper Use of Functions Problem » Multi-statement user defined functions cause poor performance Indications » Zero cost scan operator in exec plan » Very slow performance Solution » When working with more than a few (~50?) rows, don’t use them » When using operations such as JOIN that require statistics, don’t use them 13
- 14. Grant Fritchey | www.ScaryDBA.com The “Run Faster” Switch Problem » Use of the NO_LOCK query hint everywhere, or setting transaction isolation level to READ_UNCOMMITTED Indications » Extra rows in result set » Missing rows in result set Solution » Tune the queries » Tune the structures » Use snapshot isolation levels http://www.jasonstrate.com/2012/06/the-side-effect-of- nolock/ 14
- 15. Grant Fritchey | www.ScaryDBA.com Query Hints Problem » Query hints in the code such as FAST n, index hints, JOIN hints Indications » Inconsistent performance behavior » Bad performance » Odd looking execution plans Solution » Use of query hints should be exceptional » Exceptions are rare, not standard practice 15
- 16. Grant Fritchey | www.ScaryDBA.com Recompiles Problem » Excessive blocking and CPU contention caused by constant or long statement recompiles Indications » Recompile events in extended events or trace » Blocking » High CPU usage Solutions » Avoid interleaving DDL & DML » Where viable, use table variables 16
- 17. Grant Fritchey | www.ScaryDBA.com Row by Agonizing Row Problem » Cursors instead of set-based operations » WHILE loops instead of set-based operations » Multiple statements where 1 will do Indications » Extremely slow performance Solutions » Eliminate unnecessary row-by-row processing 17
- 18. Grant Fritchey | www.ScaryDBA.com Nested Views Problem » Views within views causes optimizer timeout Indications » Incredibly complex query plans for simple queries » Very poor performance Solutions » Don’t nest views » Materialize views 18
- 19. Grant Fritchey | www.ScaryDBA.com Writing for Readability Define a local standard » Object names » Comments » Format » Error handling Enforce the standard » Document it » Code reviews 19
- 20. Grant Fritchey | www.ScaryDBA.com Writing For Performance Write for your data structures Write for your indexes Write for the query optimizer Avoid common issues: » Data types » Functions in comparisons » Improper use of functions » The “run faster” switch » Inappropriate Query Hints » Recompiles » Row By Agonizing Row » NestedViews 20
- 21. Grant Fritchey | www.ScaryDBA.com Goal Learn methods for writingTSQL for readability Understand how to write TSQL for performance 21
- 22. Grant Fritchey | www.ScaryDBA.com Get in touch scarydba.com grant@scarydba.com @gfritchey Grant Fritchey
- 23. Grant Fritchey | www.ScaryDBA.com Questions? 24