Advanced SQL: CROSS APPLY and OUTER APPLY

Advanced SQL: CROSS APPLY and OUTER APPLY
4.1 (82.86%) 7 vote[s]

In this article, we’ll look into the “APPLY” operator and its variations – CROSS APPLY and OUTER APPLY along with examples of how they can be used.

In particular, we will learn:

  • the difference between CROSS APPLY and the JOIN clause
  • how to join the output of SQL queries with table-evaluated functions
  • how to identify performance issues by querying dynamic management views and dynamic management functions.

What the APPLY Clause is

Microsoft introduced the APPLY operator in SQL Server 2005. The APPLY operator is similar to the T-SQL JOIN clause as it also allows to join two tables – for example, you can join an outer table with an inner table. The APPLY operator is a good option when, one one side, we have a table-evaluated expression which we want to evaluate for each row from the table we have on another side. So, the right-side table is processed for each row of the left-side table. The left-side table is evaluated first, and then the right-side table is evaluated against each row of the left-side table to generate the final result set. The final result set includes all columns from both tables.

The APPLY operator has two variations:

  • CROSS APPLY
  • OUTER APPLY

CROSS APPLY

CROSS APPLY is similar to INNER JOIN, but can also be used to join table-evaluated functions with SQL Tables. CROSS APPLY’s final output consists of records matching between the output of a table-evaluated function and an SQL Table.

OUTER APPLY

OUTER APPLY resembles LEFT JOIN, but has an ability to join table-evaluated functions with SQL Tables. OUTER APPLY’s final output contains all records from the left-side table or table-evaluated function, even if they don’t match with the records in the right-side table or table-valued function.

Now, let me explain both variations with examples.

Usage examples

Preparing the Demo Setup

To prepare a demo setup, you will need to create tables named “Employees” and “Department” in a database we’ll call “DemoDatabase”. To do that, run the following code:

Next, insert some dummy data into both tables. The following script will insert data into the “Employees” table:

FULL QUERY

To add data to our “Department” table, run the following script:

Now, to verify the data, execute the code you can see below:

Here’s the desired output:

SQL APPLY demo tables

Creating and testing a table-evaluated function

As I already mentioned, “CROSS APPLY” and “OUTER APPLY” are used to join SQL Tables with table-evaluated functions. To demonstrate that, let’s create a table-evaluated function named “getEmployeeData.” This function will use a value from the DepartmentID column as an input parameter and return all employees from the correspondent department.

To create the function, run the following script:

Now, to test the function, we will pass “1” as “departmentID” to the “Getemployeesbydepartment” function. To do this, execute the script provided below:

The output should be as follows:

SQL APPLY function test

Joining a table with a table-evaluated function using CROSS APPLY

Now, let’s try to join the Employees table with the “Getemployeesbydepartment” table-evaluated function using CROSS APPLY. As I mentioned, the CROSS APPLY operator is similar to the Join clause. It will populate all records from the “Employee” table for which there are matching rows in the output of “Getemployeesbydepartment”.

Run the following script:

The output should be as follows:

SQL CROSS APPLY join table and function

Joining a Table with a Table-evaluated function using OUTER APPLY

Now, Let us try to join the Employees table with the “Getemployeesbydepartment” table-evaluated function using OUTER APPLY. As I mentioned before, the OUTER APPLY operator resembles the “OUTER JOIN” clause. It populates all records from the “Employee” table and the output of the “Getemployeesbydepartment” function.

Run the following script:

Here’s the output you should see as a result:

SQL OUTER APPLY join table and function

Identifying performance issues by using dynamic management functions and views

Let me show you a different example. Here, we’ll see how to get a query plan and the corresponding query text by using dynamic management functions and dynamic management views.

For demonstration purposes, I have created a table named “SmokeTestResults” in the “DemoDatabase”. It contains results of an application smoke test. Let’s imagine that, by mistake, a developer executes a SQL Query to populate the data from “SmokeTestResults” without adding a filter, which significantly reduces the database performance.

As a DBA, we need to identify the resource-heavy query. To do this, we will use the “sys.dm_exec_requests” view and the “sys.dm_exec_sql_text” function.

Sys.dm_exec_requests” is a dynamic management view which provides the following important details we can use to identify the resource-consuming query:

  1. Session ID
  2. CPU Time
  3. Wait Type
  4. Database ID
  5. Reads (Physical)
  6. Writes (Physical)
  7. Logical reads
  8. SQL Handle
  9. Plan Handle
  10. Query Status
  11. Command
  12. Transaction ID

sys.dm_exec_sql_text” is a dynamic management function which accepts an SQL handle as an input parameter and provides the following details:

  1. Database ID
  2. Object ID
  3. Is Encrypted
  4. SQL Query Text

Now, let’s run the following query to generate some stress on the ASAP database. Execute the following query:

SQL Server allocates a session ID “66” and starts the query execution. See the following image:

SQL APPLY performance heavy query

Now, to troubleshoot the issue, we require the Database ID, Logical Reads, SQL Query, Command, Session ID, Wait type and SQL Handle. As I mentioned, we can get Database ID, Logical Reads, Command, Session ID, wait Type and SQL handle from “sys.dm_exec_requests.” To get the SQL Query, we must use “sys.dm_exec_sql_text.” It’s a dynamic management function, so would need to join “sys.dm_exec_requests” with “sys.dm_exec_sql_text” by using CROSS APPLY.

In the New query editor window, run the following query:

It should produce the following output:

SQL APPLY performance issue identification

As you can see in the above screenshot, the query returned all information required to identify the performance issue.

Now, in addition to the query text, we want to get the execution plan which was used to execute the query in question. To do this, we’ll use the “sys.dm_exec_query_plan” function.

sys.dm_exec_query_plan” is a dynamic management function which accepts a plan handle as an input parameter and provides the following details:

  1. Database ID
  2. Object ID
  3. Is Encrypted
  4. SQL Query Plan in XML format

To populate the query execution plan, we must use CROSS APPLY to join “sys.dm_exec_requests” and “sys.dm_exec_query_plan.

Open the New Query editor window and execute the following query:

The output should be as follows:

SQL APPLY get query plan

Now, as you can see, the query plan is generated in XML format by default. To open it as a graphical representation, click on the XML output in the query_plan column as shown in the above image. Once you click on the XML output, the execution plan will be opened in a new window as shown in the following image:

SQL APPLY query plan format

Getting a list of tables with highly fragmented indices by using dynamic management views and functions

Let’s see one more example. I want to get a list of tables with indices that have 50% or more fragmentation in a given database. To retrieve these tables, we will need to use the “sys.dm_db_index_physical_stats” view and the “sys.tables” function.

Sys.tables” is a dynamic management view which populates a list of tables on the specific database.

sys.dm_db_index_physical_stats” is a dynamic management function which accepts the following input parameters:

  1. Database ID
  2. Object ID
  3. Index ID
  4. Partition Number
  5. Mode

It returns detailed information on the physical status of the specified index.

Now, to populate the list of fragmented indices, we must join “sys.dm_db_index_physical_stats” and “sys.tables” using CROSS APPLY. Run the following query:

The query should produce the following output:

SQL APPLY get fragmented tables

Summary

In this article, we covered the APPLY operator, its variations – CROSS APPLY and OUTER APPLY and how thy work. We have also seen how you can use them to identify SQL performance issues using Dynamic management views and dynamic management functions.

Nisarg Upadhyay

Nisarg is a SQL Server Database Administrator and Microsoft certified professional who has more than 5 years of experience with SQL Server administration and 2 years with Oracle 10g database administration. He has expertise in database design, performance tuning, backup and recovery, HA and DR setup, database migrations and upgrades. He has completed the Bachelors in Information Technology from Ganpat University.
Nisarg Upadhyay