>I am certainly no expert in SQL optimization, but in your example it seems obvious that the difference is in the inclusion of the Status.Numero in the second query. I would guess that including it as an additional parameter, rather than as a replacement, might also see the improved performance.
>
>As a pure guess, I would speculate that it in the first case it might be doing the join before the selection, then selecting on the result because the join key is not in the result set. Whereas in the second case it can do the join after the selection because the key is included.
>
>Have you tried
>
>

>SELECT Member.Numero,Status.Numero,Status.Name FROM Member;
>  INNER JOIN Status ON Member.NoStatus=Status.Numero;
>  WHERE Member.NumeroI=4112;
>  ORDER BY 1 ASC
>

Thanks, I have tried all kinds of variations, for examples, here is a list:

SELECT Member.Numero,Status.Numero,Status.AddUser FROM Member;
 INNER JOIN Status ON Member.NoStatus=Status.Numero;
 WHERE Member.NumeroI=4112;
 ORDER BY 1 ASC

SELECT Member.Numero,Status.Numero,Status.AddUser,Status.AddDate FROM Member;
 INNER JOIN Status ON Member.NoStatus=Status.Numero;
 WHERE Member.NumeroI=4112;
 ORDER BY 1 ASC

SELECT Member.Numero,Status.Numero,Status.AddUser,Status.AddDate,Status.AddUser FROM Member;
 INNER JOIN Status ON Member.NoStatus=Status.Numero;
 WHERE Member.NumeroI=4112;
 ORDER BY 1 ASC

SELECT Member.Numero,Status.Numero,Status.AddUser,Status.AddDate,Status.AddUser,Status.AddDate FROM Member;
 INNER JOIN Status ON Member.NoStatus=Status.Numero;
 WHERE Member.NumeroI=4112;
 ORDER BY 1 ASC

Then, for example, if I start removing the last fields, it will no longer be optimized. And, Status.AddDate is not even part of the where clause or in any inner join.

This is really weird. I have never seen something like that.

I recreated the related tags on all the related tables. This is not a factor. Everything seems to be ok in there. I also tried with having a tag on DELETED(), it didn't change anything either. I also packed the tables.