Which order of joins is faster? - sql-server

Question

I'm looking at a MS SQL Server database which was developed by a company that is an expert at database design (or so I'm told) and I noticed a curious pattern of JOINs/indexes. It's upside down from what I would have done, so I wonder if it has some performance benefits (the DB is fairly big).
The table structure (simplified pseudocode) is:
Table JOBS (about 1K rows):
job_id [int, primary key]
server_id [int, foreign key]
job_name [string]
Table JOB_HISTORY (about 17M rows):
history_id [int, primary key]
job_id [int, foreign key]
server_id [int, foreign key]
job_start [datetime]
job_duration [int]
Note the denormalization where the server_id is in both tables.
What they did is:
select
t1.job_name, t2.job_start, t2.job_duration
from
JOBS t1
inner join
JOB_HISTORY t2 on (t1.job_id = t2.job_id and t1.server_id = t2.server_id)
where
t1.server_id = #param_server_id
and t2.job_start >= #param_from
and t2.job_start <= #param_to
And they have indexes:
JOBS => (server_id)
JOB_HISTORY => (job_id, server_id, job_start)
In other words, when they select the rows, they first filter the jobs from JOBS table and then look up the relevant JOB_HISTORY entries. This is what the DB is forced to do, because of the indexes.
What I would have done it is the bottom-up version:
select
t1.job_name, t2.job_start, t2.job_duration
from
JOB_HISTORY t2
inner join
JOBS t1 on (t1.job_id = t2.job_id)
where
t2.server_id = #param_server_id
and t2.job_start >= #param_from
and t2.job_start <= #param_to
And a single index:
JOB_HISTORY => (server_id, job_start)
So, basically, I directly select the relevant rows from the large JOB_HISTORY and then just look for the attached data from the JOBS table.
Is there a reason to prefer one over the other?

Answer 1

Well, I was a bit bored so thought I'd re-create this for you. First setup (I'm using a numbers table to generate about 1K and 17M rows, of course, this is all random data and doesn't represent your system :) I'm also assuming theres a clustered index on each table, even though you imply you wouldn't have one.
USE TempDB;
GO
DROP TABLE IF EXISTS #Jobs;
DROP TABLE IF EXISTS #Job_History;
CREATE TABLE #Jobs
(
job_id INT IDENTITY PRIMARY KEY
,server_id INT
,job_name VARCHAR(50)
);
CREATE TABLE #Job_History
(
history_id INT IDENTITY PRIMARY KEY
,job_id INT
,server_id INT
,job_start DATETIME DEFAULT SYSDATETIME()
,job_duration INT DEFAULT ABS(CHECKSUM(NEWID())) % 5000
);
GO
INSERT INTO #Jobs
SELECT server_id = N.n
,job_name = CONVERT(VARCHAR(50), NEWID())
FROM DBA.Dim.Numbers N
WHERE n < 1000;
INSERT INTO #JOB_HISTORY
( job_id
,server_id
)
SELECT job_id = j1.job_id
,server_id = j1.server_id
FROM #Jobs j1
CROSS JOIN DBA.Dim.Numbers n
WHERE n < 17000;
Now, case 1 (their way)
DROP INDEX IF EXISTS Idx_Job_hist ON #Job_History;
CREATE NONCLUSTERED INDEX Idx_Job_Hist ON #Job_History (job_id, server_id, job_start);
DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS
DECLARE #param_server_id INT = 1234
DECLARE #param_from INT = 500
DECLARE #param_to INT = 1000
select
t1.job_name, t2.job_start, t2.job_duration
from
#JOBS t1
inner join
#JOB_HISTORY t2 on (t1.job_id = t2.job_id and t1.server_id = t2.server_id)
where
t1.server_id = #param_server_id
and t2.job_start >= #param_from
and t2.job_start <= #param_to;
And Case 2 (your way)
DROP INDEX IF EXISTS Idx_Job_hist ON #Job_History;
CREATE NONCLUSTERED INDEX Idx_Job_Hist ON #Job_History (server_id, job_start);
select
t1.job_name, t2.job_start, t2.job_duration
from
#JOB_HISTORY t2
inner join
#JOBS t1 on (t1.job_id = t2.job_id)
where
t2.server_id = #param_server_id
and t2.job_start >= #param_from
and t2.job_start <= #param_to;
And the (totally non-conclusive, because my system isn't your system...) results:
Their plan:
Your Plan:
The costs from your plan were much higher overall.
But then this is a rather artificial exercise to just prove the point - run the plans, the answer is - it depends.
(Thanks for the excuse to play with this, it was fun :)

Answer 2

The short answer here is that it doesn't really matter in what order you JOIN the tables. SQL is one of those languages where you tell the server what you want, not so much what you want it to do (**). (AKA a so-called declarative language).
The reason we are seeing different Query Plans for the two versions of your query is that they are not exactly the same. In the first one there is a requirement that server_id is identical in both tables, while in the second version this is no longer mentioned. t1.server_id can be anything there. If you re-add this requirement you'll notice that the query plans will be identical and that the server will do exactly the same thing 'under the hood' for either query.
FYI: Building on Les H's answer I took the liberty of checking what kind of index MSSQL would suggest here and not-surprisingly it came up with
CREATE NONCLUSTERED INDEX idx_test
ON [dbo].[Job_History] ([server_id],[job_start])
INCLUDE ([job_id],[job_duration])
FYI:
without the index, each query took about 1500ms to run
creating the index took about 20 seconds
with the index, each query takes about 200ms to run
(**: Yes, I'm aware that you can 'direct' what happens under the hood by means of HINTS, but experience shows that those should only be a last resort when the QO no longer is able to make sense of things. In most cases, when the statistics are up-to-date and the data layout is not extremely exotic, the Query Optimizer is ridiculously smart about finding the best way to get you the data you asked for.)