Ups, if this is you take away, then I've done something wrong.
Let me correct that: The order of columns in an index matters, not the order of conditions in the where clause.
Ups, if this is you take away, then I've done something wrong.
Let me correct that: The order of columns in an index matters, not the order of conditions in the where clause.
Not only you did a comment on previous post, but it's a comment from the author of an awesome guide [https://use-the-index-luke.com].
Markus, I can assure you, that your guide has saved a lot of machine-computed-hours over the world with less energy consumption/wasted. Great work. :)
If you have an index on <companyId, userId>, and you query with a userID only, that index wont be used. But if the index was <userId, companyId> then that index would be used. Or if you supplied both userId and companyId in your query, then either index would work.
where id in (select id from company)
sometimes will switch your query from doing a full table scan to using an index, fixing your problem for long enough to prepare a fix to add the appropriate index. Not that I've ever had to do something like that or anything.Surprisingly, it could be used in some circumstances, just not for the regular seek.
If the index is small (compared to the base table), the DBMS may decide to perform a full index scan (instead of the full table scan), especially if your SELECT list doesn't contain columns which are not in the index.
And Oracle can employ so called "skip scan" if it realizes that the number of distinct companies is small. This is essentially a separate seek under each distinct company.