Performance Order By large table with Join Hello I have a table with 206,902 records and I am struggling to improve my query:

SELECT TOP (50) [ID]
      ,[Title]
      ,[Modified]
      ,[Created]
  FROM [Data]
 Inner Join [Permission]
    On ([Data].[ID] = [Permission].[FichaID]
   AND ([Permission].[PermID] = 1 AND [Permission].[IsGroup] = 0
        OR [Permission].[PermID] IN (46, 50, 53) AND [Permission].[IsGroup] = 1
        ))
Group By [ID]
      ,[Title]
      ,[Modified]
      ,[Created]
   Order By [Created] desc




The query is running fast but using the tool SQLQueryStress with 50 iterations complement all time is 3 minutes.
If I remove the order by the query takes to run less than a second.
I have created an index on the table Data:

CREATE INDEX facervo_created ON [Data] ([Created] desc);
CREATE INDEX facervo_status ON [Data] ([_ModerationStatus]);
CREATE INDEX facervo_expiration ON [Data] ([Expiration]);
CREATE INDEX facervo_reserva ON [Data] ([Reserva]);


Index on the table Permission:

ADD CONSTRAINT perm_key PRIMARY KEY (FichaID, PermID, IsGroup)


Still not had great success in performance.
It is possible to execute this query faster?

EDIT

I removed all the index of the two tables, and created this new index:

CREATE NONCLUSTERED INDEX [ix_include1]
ON [Data]([Created] Desc)
INCLUDE ([ID]
        ,[Title]
        ,[Modified]);


Now this query taking 16 seconds, an evolution.
Is it possible to improve the most?
This is a classic performance problem. You are ordering on the columns of one table and are filtering on the columns of another.

SQL Server can either scan Data and filter out rows by seeking into the other table (the current plan). Or it can access Permission to determine the Data rows that pass the filter, and then sort this set. Both plans require a lot of data to be touched because the filter is too selective for plan 1 and to little selective for plan 2.

There is no index that is able to cover both the sort and the filter because the columns belong to different tables.

Consider creating an indexed view that contains all the columns used here. This will result in near-perfect performance because you can now index all required columns.

Or, denormalize your data model. Store permission information directly in the Data table.