What is acceptable in your environment though is and can only be determined by you and your organization. You'll start feeling the affects of index maintenance at that point. You can get away with more indexes on tables that are static and don't change much as opposed to tables with millions of updates a day.

When adding indexes you need to balance out disk space, query performance, and the performance of updating and inserting into the tables. If your 'categories' table is accessed often, you may want to consider pinning it into memory so the db server keeps it accessible without having to goto the disk all the time. If that is the case, then the index is just taking up space with no benefit. The optimizer may/should be doing this and ignoring the index. In your example you are retrieving all the columns and with only 22 rows and it may be faster to just do a table scan and sort those instead of using the index. An exception being when you only query the columns contained within the index. time) to read an index and then more I/O and time to retrieve the records associated with the matched rows. The reason being is that it takes I/O (i.e. On small tables like your 'categories' table you usually don't want or need an index and it can actually hurt performance. The amount of indexing and the line of doing too much will depend on a lot of factors.

Too many indices for index buffer