###Before we begin with the code...

#Performance

##1. Duplicated Index Scans

##2. Sort #1 - Src_UserID_Sub

##3. Sort #2 - Src_UserID with ROW_NUMBER()

##4. Hash Match

###Overall

Before we begin with the code...

Performance

1. Duplicated Index Scans

2. Sort #1 - Src_UserID_Sub

3. Sort #2 - Src_UserID with ROW_NUMBER()

4. Hash Match

Overall

This Sort is also impossible to eliminate with your current logic, otherwise the following error will be raised: The function 'ROW_NUMBER' must have an OVER clause with ORDER BY. It might be possible to do away with ROW_NUMBER(), but that might also be more harmful than beneficial, as it would likely require a loop or some other construct that is not very "SQL-ish", and in the end, the query optimizer can probably work better with this built-in function than if we rolled our own. So again, very little optimization possible. I did eliminate the SELECT * in favor of enumerating the columns, as it makes it easier to understand, and in general SELECT * should usually be avoided for a variety of reasons.

So here is the most expensive operation in your whole execution, at 31% operator cost. I'm going to quote one of the pros on DBA.StackExchange:

This Sort is also impossible to eliminate with your current logic, otherwise the following error will be raised: The function 'ROW_NUMBER' must have an OVER clause with ORDER BY. It might be possible to do away with ROW_NUMBER(), but that might also be more harmful than beneficial, as it would likely require a loop or some other construct that is not very "SQL-ish", and in the end, the query optimizer can probably work better with this built-in function than if we rolled our own. So again, very little optimization possible. I did eliminate the SELECT * in favor of enumerating the columns, as it makes it easier to understand, and in general SELECT * should usually be avoided for a variety of reasons.

So here is the most expensive operation in your whole execution, at 31% operator cost. I'm going to quote one of the pros on DBA.StackExchange:

While (2) would be difficult to replicate on a small scale, (1) and (3) are fairly simple. I modified your sample data in the following ways to match your real life code more closely:

_Note: I will make small changes mainly in formatting

While (2) would be difficult to replicate on a small scale, (1) and (3) are fairly simple. I modified your sample data in the following ways to match your real life data more closely:

Note: I will make changes mainly in formatting as we go along.