Book Image

Learn T-SQL Querying - Second Edition

By : Pedro Lopes, Pam Lahoud
Book Image

Learn T-SQL Querying - Second Edition

By: Pedro Lopes, Pam Lahoud

Overview of this book

Data professionals seeking to excel in Transact-SQL (T-SQL) for Microsoft SQL Server and Azure SQL Database often lack comprehensive resources. This updated second edition of Learn T-SQL Querying focuses on indexing queries and crafting elegant T-SQL code, catering to all data professionals seeking mastery in modern SQL Server versions and Azure SQL Database. Starting with query processing fundamentals, this book lays a solid foundation for writing performant T-SQL queries. You’ll explore the mechanics of the Query Optimizer and Query Execution Plans, learning how to analyze execution plans for insights into current performance and scalability. Through dynamic management views (DMVs) and dynamic management functions (DMFs), you’ll build diagnostic queries. This book thoroughly covers indexing for T-SQL performance and provides insights into SQL Server’s built-in tools for expedited resolution of query performance and scalability issues. Further, hands-on examples will guide you through implementing features such as avoiding UDF pitfalls, understanding predicate SARGability, Query Store, and Query Tuning Assistant. By the end of this book, you‘ll have developed the ability to identify query performance bottlenecks, recognize anti-patterns, and skillfully avoid such pitfalls.
Table of Contents (18 chapters)
1
Part 1: Query Processing Fundamentals
4
Part 2: Dos and Don’ts of T-SQL
9
Part 3: Assembling Our Query Troubleshooting Toolbox

Best practices for T-SQL querying

There are a number of best practices for writing good T-SQL that don’t constitute a pattern or anti-pattern, which is something we will discuss next in this chapter, but are important enough to observe when we want to write good queries. This section covers those practices.

Referencing objects

Always reference objects by their two-part name (<schema>.<name>) in T-SQL code because not doing so has some performance implications.

Using two-part object names prevents name resolution delays during query compilation: if the default schema for a user connecting to the SQL Database Engine is HumanResources, and that user attempts to execute the stored procedure dbo.uspGetEmployeeManagers for which it also has permissions, but simply references uspGetEmployeeManagers, the SQL Database Engine first searches the HumanResources schema for that stored procedure before searching other schemas, thus delaying resolution and therefore execution...