Best index structure for performance

Question

I have a table with the following structure and a list of frequent queries made. Only looking at indexes, what is the recommended index structure for the table that will provide best performance? The table has 2+ million rows.

Table Structure:
id int(10) unsigned not_null auto_increment
dateDeleted datetime null
tenantId int(10) unsigned not_null
userId int(10) unsigned default 0
status tinyint(3) unsigned default 0
priority tinyint(3) unsigned default 0
docnum varchar(20) not_null

Frequent Queries:
where tenantId=? and dateDeleted is null;
where tenantId=? and dateDeleted is null and docnum=?
where tenantId=? and dateDeleted is null and status=?
where tenantId=? and dateDeleted is null and priority=?
where tenantId=? and dateDeleted is null and userId=?
where tenantId=? and dateDeleted is null and status=? and priority=?
where tenantId=? and dateDeleted is null and status=? and priority=? and userId=?
where tenantId=? and dateDeleted is null and status=? and userId=?
where tenantId=? and dateDeleted is null and priority=? and userId=?

Answer 1

If tenantId is a foreign key (its name suggests it is), then it is an obvious choice for an index:

create index mytable_tenantId_index on mytable(tenantId);

It there are a reasonable amount on tenants (more than a dozen or so), you'll find this index will give a big performance improvement. The more tenants there are, the bigger the improvement.

This index is enough, because you're already cutting down the rows drastically by just applying the condition on tenantId . Also, your query conditions do not have a condition for tenantId being null , so you don't have to cater for that edge case.

Answer 2

Indexing is a matter of tradeoff between space and performance -- of course indexing all columns you use in the queries would be the most efficient, however, the indexes will take up more space on your server. From the look of your queries, you clearly need to index tenantId and probably should index dateDeleted. If specifying a tenantId significantly reduces the size of your resultset, then sequential scans over the remaining columns may perform fine. Again, this is a matter of space vs performance, as well as the specifics of your data set.

Answer 3

Similar to what slessans said : Adding an index increases the speed of SELECT queries, but lowers it for eg INSERT (because index should be (re)calculated on adding a new row), so you should find a balance between those two.
Good practice is to index columns that appear often in JOIN and WHERE clauses, but keep in mind that indexing a column with a lot of NULL values doesn't make sense, neither does indexing a column that holds very limited number of different values (eg gender).

I hope this helps...