10 Ways To Abuse T-SQL
•Download as PPTX, PDF•
3 likes•2,456 views
This document discusses 10 common mistakes made when writing T-SQL code. It provides examples and explanations for each mistake, including: using procedural coding instead of set-based methods, overusing user-defined functions and views which can hurt performance, using SELECT * instead of specifying columns, writing non-SARGable queries, relying on "bandaid" fixes instead of proper logic, mixing mismatched data types, improperly handling NULL values, specifying unnecessary or incorrect ordering, and writing single-row triggers that don't account for multiple rows. The document emphasizes the importance of set-based coding, proper data handling, and avoiding shortcuts that can lead to performance and logic issues.
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to 10 Ways To Abuse T-SQL
Similar to 10 Ways To Abuse T-SQL (20)
Recently uploaded
Recently uploaded (20)
10 Ways To Abuse T-SQL
- 1. 10 Ways To Abuse T-SQL Common performance mistakes, coding errors, and how to prevent them
- 2. Tracy McKibben DBA Supervisor, Senior SQL Server DBA Pearson VUE Blog: realsqlguy.com Twitter: @RealSQLGuy I’m not saying I’m Batman, I’m just saying that nobody has ever seen me and Batman in the same room together...
- 3. 10 Ways To Abuse T-SQL • Procedural coding • User-defined functions • Views • SELECT * • Non-SARGable queries • Bandaids • Mismatched Data Types • NULL • Incorrect or unnecessary ordering • Single-row triggers
- 4. Procedural Coding Symptoms include: • loops • cursors • repeated SQL statements • temp tables • if/else structures
- 5. Procedural Coding Comparable to carrying groceries to the car one item at a time, when you could be using this instead.
- 6. Procedural Coding Help your DBA out, learn set-based coding methods. Be a team player.
- 7. User-Defined Functions Useful for • code re-use • packaging complex logic • readability
- 8. User-Defined Functions Useful for • code re-use • packaging complex logic • Readability • killing performance • complicating query tuning • inducing DBA nightmares
- 9. User-Defined Functions Functions have their place, but they're not always the right tool for the job.
- 10. Views Like user-defined functions, views can be used to • re-use code • hide complex queries • make large queries more readable
- 11. Views But what's lurking beneath the surface?
- 12. Views Views can hide some scary performance issues. Make sure your view is clear.
- 13. SELECT * Are you SURE you want the whole thing?
- 14. SELECT * What's wrong with SELECT *? • prone to table scans or lookups • difficult to support with indexes • widely considered sloppy and "lazy“ • dangerous in views
- 15. SELECT * Be a hero. Don't use SELECT * in code that counts.
- 16. Non-SARGable Queries What is a SARGable query? A query that is Search ARGument-able. What does that mean?
- 17. Non-SARGable Queries Which of these are SARGable expressions? • SalesPersonID <> 10 • SalesPersonID = 99 • SalesPersonID >= 100 • SalesPersonID NOT IN (some subquery) • SalesPersonID IN (some subquery) • SalesPersonID IS NULL • ISNULL(SalesPersonID, 0) = 0
- 18. Non-SARGable Queries Which of these are SARGable expressions? • SalesPersonID <> 10 * • SalesPersonID = 99 • SalesPersonID >= 100 • SalesPersonID NOT IN (some subquery) • SalesPersonID IN (some subquery) • SalesPersonID IS NULL • ISNULL(SalesPersonID, 0) = 0 ** * SQL 2008+ ** sargable if column is NOT NULLable
- 19. Non-SARGable Queries SARG makes DBA's happy!
- 20. Bandaids Don't use bandaids when corrective surgery is required
- 21. Bandaids T-SQL makes it easy, too easy, to cover up coding mistakes, often with a price. • DISTINCT (don't hide dupes, stop fetching them in the first place) • NOLOCK (this is NOT the cure for blocking) • UNION (figure out the logic for a proper WHERE clause)
- 22. Bandaids Be tough - rip off the bandaids! Ya big crybaby....
- 23. Mismatched Data Types Wrong. So wrong. Some comparisons should never be made.
- 24. Mismatched Data Types Some transformations conversions work just fine. Some create performance problems. Some just fail miserably. Watch out for: • NVARCHAR to VARCHAR • character to numeric • datetime manipulations to remove time, DATEDIFF
- 25. Mismatched Data Types Keep your data types compatible
- 26. NULL Improper handling of NULL values can lead to errors and/or incorrect results.
- 27. NULL • NULL has NO VALUE • NULL does not mean zero • NULL does not mean blank • NULL does not mean an empty string • NULL means NULL
- 28. NULL NULL values aren't difficult to work with, but be sure to read the fine print.
- 29. Incorrect/Unnecessary Ordering Don't make assumptions about how data will be ordered. If a specific order is required, specify it.
- 30. Incorrect/Unnecessary Ordering Without ORDER BY, the query optimizer will surprise you with a "random" sort order, dictated by the fastest query plan it could find. Specifying an ORDER BY can affect the query plan selected, thus affecting the performance of the query.
- 31. Incorrect/Unnecessary Ordering Sometimes the order of things doesn't matter, sometimes it makes all the difference.
- 32. Single-row Triggers This kind of thinking has no place in this movie. Nor does it belong inside a trigger. Triggers fire per operation, not per row, and must be written to handle multi-row operations.
- 33. Single-row Triggers Sometimes there should be only one, but not inside a trigger.
- 34. Lessons Learned • Use set-based methods • Be careful with user-defined functions and views • SELECT * - lazy and dangerous • Always obey SARG • Don’t use bandaids • Watch your data types • NULL – it’s not nothing • Order your results carefully • Triggers – many rows, not one
- 35. Any Questions?