Which indexes do i need to create on an sql table in order for a certain query to run fast in al cases?

A database can only only have one clustered index (which contains data) and upto 249 non-clustered indexes (contains pointers to data). Having any index will always speed up queries as it doesn't have to trawl through the entire table.
The best way to optimize indexes is to use the DAtabase Engine Tuning Advisor to find out what indexes you need.

i have tried different combination of clustered and  non clustered indexes. Also have tried to use Database Engine Tuning Advisor. It doesn't show any improvements that can be made.

I will try to explain in more details:

If are many matches done by the full text catalog than the optimal execution would be to scan through the clustered index which has the first column Time enter and match the result of full text catalaog.

If are few matches done by the full text catalog than the optimal execution would be to seek through a non clustered index which has the first column Id(second Id_RoleSet and third TimeEnter desc) and match the results of full text catalog.

If I force the queries using with(index()) than the queries perform optimal. But for me is impossible to know in general if a word is often present in the table.

Another approach that i have tried is to use parameter sniffing. So when the query is executed the sql would include the search keyword in the execution plan  decision algorithm.

Thanks for your reply and hope that the problem is more clear now

How many items do you expect in the IN clause?

Maximum 6300 but in average 3000. That part is quite optimal in all cases.

In the execution plan is always high the cost of the full text catalog search in conjunction with one of the indexes.

Maximum 6300 but in average 3000. That part is quite optimal in all cases.
I would look into saving that many items into a table, so that you can JOIN against it instead of using IN.  This way you can build a non-dynamic query (preferably in a Stored Procedure) that will always give you consistent and above par results as it can re-use the same plan over and over again.

We are doing that already i just didn't include that part so it looks more clear the problematic part.

I think I found a solution. I will post after additional testing if it proves to be the correct one.

Thanks again for your help.

For this specific query, you'd want the clustered index to be on:
Id_RoleSet

To speed up the text searching, you could also consider "pre-searching" common phrases.   I suggest using bit masks in an int, or smallint, column for that.  

And/or you could cache previous search results using a separate table, in case the same text searches are done multiple times.

This is the query that works in most cases optimal now

create table #docs (Id  int)

insert into #docs
select doc_main.Id
from doc_Main
where Id_RoleSet in (1,2,..........)
      and
      (
      CONTAINS((doc_Main.Subject, doc_Main.Body), '"regards"')  
      )

create nonclustered index temp_docs on #docs(Id)

SELECT TOP 250 doc_Main.Id,doc_Main.Gid,doc_Main.Name,doc_Main.TimeEnter,doc_Main.Prio,doc_Main.Direction,doc_Main.Status,doc_Main.CreaterId,doc_Main.Subject, doc_Main.Body,
doc_Main.BodyType,doc_Main.Attach,doc_Main.FromAddr,doc_Main.ToAddr,doc_Main.Gid_LineSet,doc_Main.XML, COALESCE(doc_Attrib.IsRead,0) as DocRead ,
(SELECT Ref FROM doc_Ref WHERE doc_Ref.Id_Doc=doc_Main.Id And doc_Ref.RefType= 2) as ExtraField2  

FROM doc_Main
      LEFT JOIN doc_Attrib ON doc_Main.Id = doc_Attrib.Id_Doc AND doc_Attrib.Gid_User = '{c6358127-8944-48dc-a8df-7a6da3826cee}'       
WHERE
       doc_Main.Id in (select Id
      from #docs
      
       )
ORDER BY doc_Main.TimeEnter DESC
--option(recompile)

drop table #docs


It looks extremely ugly.

I have tried with Id_RoleSet as clustered index but it does not help a lot.

Another limitation set for all the queries in the system is that there is a timeout of 30 seconds. Which i would like to keep. So if it would take more than 30 seconds anyway there is no way to cache because the query is canceled. If is under 30 than no need.

Thanks for your advice.

It works really nice. Thank you. I will do some additional tests tomorrow.
CREATE UNIQUE CLUSTERED INDEX temp_docs ON #docs(Id)
I have replaced it with
CREATE UNIQUE NONCLUSTERED INDEX temp_docs ON #docs(Id)

it looks that the clustered index on temp table is much more expensive and is not needed in this cases as far as i can see.

it looks that the clustered index on temp table is much more expensive and is not needed in this cases as far as i can see.
It is fundamental to achieve best performance.  But you are the best judge of that.

Thanks for your help. It works well in most of the cases.