10 Ways To Abuse T-SQL
Download as PPTX, PDF3 likes2,485 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.
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?