mysql too many indexes?

I am spending some time optimizing our current database.

I am looking at indexes specifically.

There are a few questions:

• Is there such a thing as too many indexes?
• What will indexes speed up?
• What will indexes slow down?
• When is it a good idea to add an index?
• When is it a bad idea to add an index?
• Pro's and Con's of multiple indexes vs multi-column indexes?

> What will indexes speed up?

Data retrieval -- SELECT statements.

> What will indexes slow down?

Data manipulation -- INSERT, UPDATE, DELETE statements.

> When is it a good idea to add an index?

If you feel you want to get better data retrieval performance.

>When is it a bad idea to add an index?

On tables that will see heavy data manipulation -- insertion, updating...

>Pro's and Con's of multiple indexes vs multi-column indexes?

Queries need to address the order of columns when dealing with a covering index (an index on more than one column), from left to right in index column definition. The column order in the statement doesn't matter, only that of columns 1, 2 and 3 - a statement needs have a reference to column 1 before the index can be used. If there's only a reference to column 2 or 3, the covering index for 1/2/3 could not be used.

In MySQL, only one index can be used per SELECT/statement in the query (subqueries/etc are seen as a separate statement). And there's a limit to the amount of space per table that MySQL allows. Additionally, running a function on an indexed column renders the index useless - IE:

WHERE DATE(datetime_column) = ...

I disagree with some of the answers on this question.

> Is there such a thing as too many indexes?

Of course. Don't create indexes that aren't used by any of your queries. Don't create redundant indexes. Use tools like pt-duplicate-key-checker and pt-index-usage to help you discover the indexes you don't need.

> What will indexes speed up?

• Search conditions in the WHERE clause.
• Join conditions.
• Some cases of ORDER BY.
• Some cases of GROUP BY.
• UNIQUE constraints.
• FOREIGN KEY constraints.
• FULLTEXT search.

Other answers have advised that INSERT/UPDATE/DELETE are slower the more indexes you have. That's true, but consider that many uses of UPDATE and DELETE also have WHERE clauses and in MySQL, UPDATE and DELETE support JOINs too. Indexes may benefit these queries more than making up for the overhead of updating indexes.

Also, InnoDB locks rows affected by an UPDATE or DELETE. They call this row-level locking, but it's really index-level locking. If there's no index to narrow down the search, InnoDB has to lock a lot more rows than the specific row you're changing. It can even lock all the rows in the table. These locks block changes made by other clients, even if they don't logically conflict.

> When is it a good idea to add an index?

If you know you need to run a query that would benefit from an index in one of the above cases.

> When is it a bad idea to add an index?

If the index is a left-prefix of another existing index, or the index doesn't help any of the queries you need to run.

> Pro's and Con's of multiple indexes vs multi-column indexes?

In some cases, MySQL can perform index-merge optimization, and either union or intersect the results from independent index searches. But it gives better performance to define a single index so the index-merge doesn't need to be done.

For one of my consulting customers, I defined a multi-column index on a many-to-many table where there was no index, and improved their join query by a factor of 94 million!

Designing the right indexes is a complex process, based on the queries you need to optimize. You shouldn't make broad rules like "index everything" or "index nothing to avoid slowing down updates."

See also my presentation How to Design Indexes, Really.

> Is there such a thing as too many indexes?

Indexes should be informed by the problem at hand: the tables, the queries your application will run, etc.

> What will indexes speed up?

SELECTs.

> What will indexes slow down?

INSERTs will be slower, because you have to update the index.

> When is it a good idea to add an index?

When your application needs another WHERE clause.

> When is it a bad idea to add an index?

When you don't need it to query or enforce uniqueness constraints.

> Pros and Cons of multiple indexes vs multi-column indexes?

I don't understand the question. If you have a uniqueness constraint that includes multiple columns, by all means model it as such.

> Is there such a thing as too many indexes?

Yes. Don't go out looking to create indexes, create them as necessary.

> What will indexes speed up?

Any queries against the indexes table/view.

> What will indexes slow down?

Any INSERT statements against the indexed table will be slowed down, because each new record will need to be indexed.

> When is it a good idea to add an index?

When a query is not running at an acceptable speed. You may be filtering on records that are not part of the clustered PK, in which case you should add indexes based on the filters you are searching upon (if the performance deems fit).

> When is it a bad idea to add an index?

When you do it for the sake of it - i.e over-optimization.

> Pro's and Con's of multiple indexes vs multi-column indexes?

Depends on the queries you are trying to improve.

> Is there such a thing as too many indexes?

Yup, like all things, too many indexes will slow down data manipulation.

> When is it a good idea to add an index?

A good idea to add an index is when your queries are too slow (i.e. you have too many joins in your queries). You should use this optimization only after you built a solid model, to tweak the performance.