In other words, let’s say this is my table:
tbl_rel
- id
- groupID
- created
Index 1 on id
Index 2 on groupID
OR
Index 1 on id and groupID
I want to know if those are equivalent for any query involving the keys (see the queries below):
SELECT * FROM tbl_rel WHERE id = 1
Does this use indexes in either of the index cases above?
SELECT * FROM tbl_rel WHERE id = 1 AND groupID = 5
Does this use indexes in either of the index cases above?
Thanks all, it’s been hard to find an answer on this. I hope my question makes sense.
Typically, btree indexes typically work left to right against the list of columns that make up that index to determine if they can be used by a query; so an index on id and groupid is an index first on the id, and then on the groupid. If the query doesn’t use id in a query, then it won’t be used because it can’t work against the first column defined in the index.
Will use an index on id; or an index on id and groupid (if there isn’t any index just on the id) even though groupid is included in the index but isn’t part of the query; but won’t even look at any index on just groupid.
Will use an index on id and groupid if it exists (because both id and groupid are part of the WHERE clause); or an index on id (if there isn’t any index on id and groupid); or will use an index on groupid if there is no index on id, and no index on id and groupid.
Will not use an index on id; or an index on id and groupid, because id is not part of the WHERE clause; but will use an index on groupid if it exists.
If there are several indexes that can be used for the query, then the database engine will normall try to identify the most appropriate index to use based on a set of “efficiency” rules… a reasonably good description is given in this post
MySQL supports either btree or hash indexes. It’s worthwhile to read up on the differences between the two, and the situations where it is appropriate to use the different types. I don’t believe MySQL supports binary indexes (even in its latest versions)