About redundant and duplicate indexes in mysql

MySQL allows multiple indexes to be created on the same column. Whether intentionally or unintentionally, MySQL needs to maintain duplicate indexes separately, and the optimizer needs to consider them one by one when optimizing queries, which will affect performance.

Duplicate indexes refer to indexes of the same type that are created on the same columns in the same order. You should avoid creating duplicate indexes in this way and delete them immediately after discovery. However, it is possible to create different types of indexes on the same columns to meet different query needs.

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 3 duplicate indexes. There's usually no reason to do this.

There are some differences between redundant indexes and duplicate indexes. If you create index (a, b), and then create index (a), it is a redundant index, because this is just the prefix index of the previous index, so (a ,b) can also be used as (a), but (b,a) is not a redundant index, nor 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 for B-Tree indexes, regardless of the covered index columns.

Redundant indexes usually occur when new indexes are added to the table. For example, one might add a new index (A,B) instead of extending a later index (A). Another situation is to extend 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. You should try to expand existing indexes instead of creating new indexes. However, sometimes performance considerations require redundant indexes, because expanding existing indexes will causing it to become too large, affecting the performance of other queries that use the index. For example: If there is an index on an integer column, and now you need to add a very long varchar column to expand the index, then the performance may drop sharply, especially if there are queries that use this index as a covering index, or this is a myisam table And when there are many range queries (due to myisam's prefix compression)

For example, there is a userinfo table. This table has 1,000,000 records, approximately 20,000 records for each state_id value. There is an index on state_id, then we call the following SQL Q1

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

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

There is another SQL, we 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 index (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 duplication. Index)

How to find redundant indexes and duplicate indexes?

1. You can use some attempts in Shlomi Noach's common_schema to locate. common_schema is a series of commonly used storage and attempts 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.

The above is the detailed content of About redundant and duplicate indexes in mysql. For more information, please follow other related articles on the PHP Chinese website!