Detailed explanation of redundant and duplicate indexes in MySQL

MySQL allows you to create multiple indexes on the same column. Whether intentional or unintentional, MySQL needs to maintain duplicate indexes separately, and the optimizer also needs to consider them one by one when optimizing queries, which affects performance.

Duplicate indexes refer to indexes of the same type created on the same columns in the same order. You should avoid creating duplicate indexes in this way and delete them immediately if you find them. However, it is possible to create different types of indexes on the same column to meet different query requirements.

CREATE TABLE test(
 ID INT NOT NULL PRIMARY KEY,
 A INT NOT NULL,
 B INT NOT NULL,
 UNIQUE(ID),
 INDEX(ID),
)ENGINE=InnoDB;

This SQL creates three duplicate indexes. There is usually no reason to do this.

There are some differences between redundant indexes and duplicate indexes. If you create an index (a, b), then creating an index (a) is a redundant index because it is only a prefix index of the previous index. Therefore, (a, b) can also be used as (a), but (b, a) is not a redundant index, and neither is index (b) because b is not the leftmost prefix column of index (a, b). In addition, other different types of indexes created on the same columns (such as hash indexes and full-text indexes) will not be redundant indexes of B-Tree indexes, regardless of the covered index columns.

Redundant indexes usually occur when adding new indexes to a table. For example, one might add a new index (A,B) instead of extending the existing index (A). Another case is to expand an index to (A, ID), where ID is the primary key. For InnoDB, the primary key is already included in the secondary index, so this is also redundant.

In most cases, redundant indexes are not needed, and you should try to expand existing indexes instead of creating new ones. However, sometimes redundant indexes are needed for performance reasons, because expanding an existing index will cause it to become too large, thus affecting the performance of other queries that use the index. For example, if you have an index on an integer column and now need to add an extra long varchar column to extend the index, the performance may drop dramatically, especially if there are queries that use this index as a covering index, or if this is a MyISAM table and there are many range queries (due to MyISAM prefix compression).

For example, there is a userinfo table. This table has 1,000,000 records, with about 20,000 records for each state_id value. There is an index on state_id, so the following SQL is called Q1

SELECT count(*) FROM userinfo WHERE state_id=5; --Q1

The query execution speed is about 115 times per second (QPS)

There is another SQL, let's call it Q2

SELECT state_id,city,address FROM userinfo WHERE state_id=5; --Q2

The QPS of this query is 10. The easiest way to improve the performance of this index is to use a wild war index of (state_id, city, address) so that the index can cover the query:

ALERT TABLE userinfo ADD KEY state_id_2(state_id,city,address);

Note: state_id already has an index. According to the previous concept, this is a redundant index rather than a duplicate index)

How to find redundant indexes and duplicate indexes?

1. You can use some views in Shlomi Noach's common_schema to locate it. common_schema is a set of common storage and views that can be installed on the server.

2. You can use pt_duplicate-key-checker in Percona Toolkit, which analyzes the table structure to find redundant and duplicate indexes.

Summarize

The above is all the content of this article about the detailed explanation of redundant and duplicate indexes in MySQL. I hope it will be helpful to everyone. Interested friends can refer to: Several important MySQL variables, a brief description of the difference between Redis and MySQL, MYSQL subquery and nested query optimization example analysis, etc. If there are any deficiencies, please leave a message and point them out. The editor will reply to you in time and make modifications. Thank you friends for your support of this site!