Optimize Query Join Between Dates - sql

Question

3 tables
WorkRecordfact - has workdate(date) - ~300000 rows
EmployeeStatus - Startdate(date), EndDate(date), PositionID - 450 Rows
Positions - PositionID, PositionCode - 10 rows
Queries that look for data in WorkRecordFact filtering by position are taking a long time. Basic sample Query
SELECT workrecordfact.*
FROM workrecordfact
INNER JOIN Employeestatus on
Employeestatus.EmployeeID = workrecordfact.EmployeeID and
employeestatus.startdate <= workrecordfact.workdate and
employeestatus.enddate >= workrecordfact.workdate
INNER JOIN Positions on
employeestatus.PositionID = positions.PositionID
Where workrecordfact.workdate >= '20180601'
and workrecordfact.workdate <= '20180930'
and PositionCode = 'CSR'
Workrecordfact has a clustered index on Workdate
Employeestatus has 4 indexes
EmployeeID
EmployeeID+ StartDate
EmployeeID+ EndDate
EmployeeID+ StartDate + EndDate
In the query Statistics I'm seeing a lot of 500% elements. Starting with a Clustered Index Seek on the WorkRecordFact index. Some numbers that stand out
Estimated Number of Rows 250
Estimated Number of Rows to be Read 667
Number of Executions 381
Number of Rows Read 49525952??!?!?
Actual Number of Rows 112018
Results are taking long enough that the .net app sending the query is receiving a timeout in some cases.
I've rebuild/reorganized fragmented indexes, and refreshed statistics but that's not solved the issue.
Any Ideas?
UPDATE: It seems the query is running quite well from SMSS and only timing out from the application. Dates are passed in as parameters BTW, currently investigating possible issues with parameter sniffing :-/

Answer 1

Since workrecordfact has lot more records than EmployeeStatus and is a date range query.
First indexing them is always a pain.
Secondly Drop indexes on Employee Status they are of no use with regard to this query in my opinion.
EmployeeID
EmployeeID+ StartDate
EmployeeID+ EndDate
EmployeeID+ StartDate + EndDate
Create one more for EmployeeID on the fact table.
I think that should help.

Answer 2

The name of the game is to limit IO on the workrecordfact table. The way the query and indexing are currently set up, we're scanning 100% of the work in the third quarter, then later filtering that down to just the work of the CSRs. I wonder if the CSR criteria might be more selective and get us to a lower number of rows read?
This query is pretty zippy, right?
SELECT es.EmployeeID, es.StartDate, es.EndDate
FROM Positions p
JOIN Employeestatus es
ON p.PositionID = es.PositionID
WHERE PositionCode = 'CSR'
'CSR' probably matches exactly one Positions row. Assuming positions do approximately equal work, we probably only need to read 10% of the Q3 portion of the work table.
Thinking about bringing in the work facts afterwards like this.
SELECT w.*
FROM
(
SELECT es.EmployeeID, es.StartDate, es.EndDate
FROM Positions p
JOIN Employeestatus es
ON p.PositionID = es.PositionID
WHERE PositionCode = 'CSR'
) es2
JOIN workrecordfact w
ON es2.EmployeeID = w.EmployeeID
AND es2.startdate <= w.workdate AND w.workdate <= es2.enddate
WHERE
'2018-06-01' <= w.workdate AND w.workdate <= '2018-09-30'
This query would be best supported by this index:
CREATE INDEX WorkRecordFact_EmployeeId_WorkDate ON WorkRecordFact(EmployeeId, WorkDate)
Moving the conditional choice of workdate logically earlier into the query might be helpful:
SELECT w.*
FROM
(
SELECT es.EmployeeID,
CASE WHEN es.StartDate <= '2018-06-01' THEN '2018-06-01' ELSE es.StartDate END as StartDate,
CASE WHEN '2018-09-30' <= es.EndDate THEN '2018-09-30' ELSE es.EndDate END as EndDate
FROM Positions p
JOIN Employeestatus es
ON p.PositionID = es.PositionID
WHERE PositionCode = 'CSR'
) es2
JOIN workrecordfact w
ON es2.EmployeeID = w.EmployeeID
AND es2.startdate <= w.workdate AND w.workdate <= es2.enddate