Performance Optimization and Semantic Differences of INNER JOIN with DISTINCT in SQL Server

Nov 23, 2025 · Programming · 10 views · 7.8

Keywords: SQL Server | INNER JOIN | DISTINCT Optimization

Abstract: This article provides an in-depth analysis of three implementation approaches for combining INNER JOIN and DISTINCT operations in SQL Server. By comparing the performance differences between subquery DISTINCT, main query DISTINCT, and traditional JOIN methods, we examine their applicability in various scenarios. The focus is on analyzing the semantic changes in Denis M. Kitchen's optimized approach when duplicate records exist, accompanied by detailed code examples and performance considerations. The article also discusses the fundamental differences between HTML tags like <br> and character \n, helping developers choose optimal query strategies based on actual data characteristics.

Introduction

In database query optimization, the combination of INNER JOIN and DISTINCT is a common scenario that often leads to performance issues. Based on classic Q&A from Stack Overflow, this article systematically analyzes three different implementation approaches and their performance in SQL Server.

Problem Background

The original query attempted to retrieve FirstName, LastName, and District information from AddTbl and ValTbl tables, but needed to ensure unique LastName values from ValTbl. The user's initial attempt contained syntax errors:

select a.FirstName, a.LastName, v.District
from AddTbl a order by Firstname
inner join (select distinct LastName from
            ValTbl v  where a.LastName = v.LastName)

Main issues included incorrect ORDER BY placement and incomplete subquery logic.

Solution Comparison

Approach 1: Subquery DISTINCT

The first optimization uses DISTINCT in a subquery to filter duplicate records early:

select a.FirstName, a.LastName, v.District
from AddTbl a 
inner join (select distinct LastName, District 
    from ValTbl) v
   on a.LastName = v.LastName
order by Firstname

This approach reduces the data volume for JOIN operations, offering significant performance benefits when ValTbl contains numerous duplicate LastName values.

Approach 2: Main Query DISTINCT (Recommended)

As the best answer, this approach applies DISTINCT to the final result set:

select distinct a.FirstName, a.LastName, v.District
from AddTbl a 
  inner join ValTbl v
  on a.LastName = v.LastName
order by a.FirstName;

Or using traditional WHERE syntax:

select distinct a.FirstName, a.LastName, v.District
from AddTbl a, ValTbl v
where a.LastName = v.LastName
order by a.FirstName;

Semantic Difference Analysis

Denis M. Kitchen's 2023 update highlights that Approach 1 may produce different results. When AddTbl contains identical <code>(FirstName, LastName)</code> combinations, Approach 2 preserves all matching records, while Approach 1 only returns unique LastName matches.

For example, if AddTbl has two records: <code>(&quot;John&quot;, &quot;Doe&quot;)</code> and <code>(&quot;John&quot;, &quot;Doe&quot;)</code>, and ValTbl has one record: <code>(&quot;Doe&quot;, &quot;DistrictA&quot;)</code>:

Performance Considerations

From a performance perspective, Approach 1 excels when ValTbl is large with many duplicates, as DISTINCT executes before JOIN. Approach 2 may generate more intermediate results when AddTbl has numerous duplicate records but ensures data integrity.

Technical Details Supplement

In string processing, special character escaping is crucial. For example, when printing HTML tags in code: <code>print(&quot;&lt;T&gt;&quot;)</code> requires escaping angle brackets. Similarly, when discussing HTML tags, &lt;br&gt; as text content needs escaping, distinguishing it from actual line break tags.

Conclusion

The choice between approaches depends on specific business requirements: use Approach 2 for complete matching records, and Approach 1 for performance optimization when record deduplication is acceptable. In practical development, testing should guide selection based on data distribution and business logic.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.