Successfully reported this slideshow.
Your SlideShare is downloading. ×

10 Ways To Abuse T-SQL

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
Perfect Code
Perfect Code
Loading in …3
×

Check these out next

1 of 35 Ad
Advertisement

More Related Content

Viewers also liked (20)

Similar to 10 Ways To Abuse T-SQL (20)

Advertisement

Recently uploaded (20)

10 Ways To Abuse T-SQL

  1. 1. 10 Ways To Abuse T-SQL Common performance mistakes, coding errors, and how to prevent them
  2. 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. 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. 4. Procedural Coding Symptoms include: • loops • cursors • repeated SQL statements • temp tables • if/else structures
  5. 5. Procedural Coding Comparable to carrying groceries to the car one item at a time, when you could be using this instead.
  6. 6. Procedural Coding Help your DBA out, learn set-based coding methods. Be a team player.
  7. 7. User-Defined Functions Useful for • code re-use • packaging complex logic • readability
  8. 8. User-Defined Functions Useful for • code re-use • packaging complex logic • Readability • killing performance • complicating query tuning • inducing DBA nightmares
  9. 9. User-Defined Functions Functions have their place, but they're not always the right tool for the job.
  10. 10. Views Like user-defined functions, views can be used to • re-use code • hide complex queries • make large queries more readable
  11. 11. Views But what's lurking beneath the surface?
  12. 12. Views Views can hide some scary performance issues. Make sure your view is clear.
  13. 13. SELECT * Are you SURE you want the whole thing?
  14. 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. 15. SELECT * Be a hero. Don't use SELECT * in code that counts.
  16. 16. Non-SARGable Queries What is a SARGable query? A query that is Search ARGument-able. What does that mean?
  17. 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. 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. 19. Non-SARGable Queries SARG makes DBA's happy!
  20. 20. Bandaids Don't use bandaids when corrective surgery is required
  21. 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. 22. Bandaids Be tough - rip off the bandaids! Ya big crybaby....
  23. 23. Mismatched Data Types Wrong. So wrong. Some comparisons should never be made.
  24. 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. 25. Mismatched Data Types Keep your data types compatible
  26. 26. NULL Improper handling of NULL values can lead to errors and/or incorrect results.
  27. 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. 28. NULL NULL values aren't difficult to work with, but be sure to read the fine print.
  29. 29. Incorrect/Unnecessary Ordering Don't make assumptions about how data will be ordered. If a specific order is required, specify it.
  30. 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. 31. Incorrect/Unnecessary Ordering Sometimes the order of things doesn't matter, sometimes it makes all the difference.
  32. 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. 33. Single-row Triggers Sometimes there should be only one, but not inside a trigger.
  34. 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. 35. Any Questions?

×