Por que pt-duplicate-key-checker sugere a remoção de um índice composto?

A chave primária é uma parte de qualquer chave secundária no InnoDB.

Discordo da análise dada pela ferramenta.

Quando vejo INDEX(bar, foo), suponho que haja alguma consulta que precise que essas duas colunas, nessa ordem, estejam nesse índice composto.

O fato de fooser o PK, e INDEX(bar)ser idêntico ao índice acima é irrelevante.

Quando vejo apenas INDEX(bar), suponho que há alguma consulta que precisa (bar)sem id.

Quando eu vir os dois, direi que o mais curto é 'redundante' e recomendo removê-lo.

Além disso, "Para encurtar este índice clusterizado duplicado" está errado . INDEX(bar)não é 'mais curto' do que INDEX(bar, foo). E não é um "índice clusterizado. Apenas o PK é "clusterizado".

Se fosse UNIQUE(bar, foo), então eu recomendaria mudar UNIQUEpara INDEX. Isso é para que INSERTsnão seja necessário fazer uma verificação de exclusividade desnecessária.

Vamos criar uma tabela simples e ver o que o MySQL (5.7.20 MySQL Community Server) tem a nos dizer:

mysql> create table test_dupe_key (foo int unsigned not null auto_increment primary key, bar int unsigned not null, random int unsigned not null default 0, key(bar, foo)) engine=InnoDB;
Query OK, 0 rows affected (0.08 sec)

mysql> show create table test_dupe_key\G
*************************** 1. row ***************************
       Table: test_dupe_key
Create Table: CREATE TABLE `test_dupe_key` (
  `foo` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `bar` int(10) unsigned NOT NULL,
  `random` int(10) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`foo`),
  KEY `bar` (`bar`,`foo`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

mysql> insert into test_dupe_key(bar) values (1), (2), (3);
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> select * from test_dupe_key;
+-----+-----+--------+
| foo | bar | random |
+-----+-----+--------+
|   1 |   1 |      0 |
|   2 |   2 |      0 |
|   3 |   3 |      0 |
+-----+-----+--------+
3 rows in set (0.00 sec)

Aqui está uma consulta simples que pode ser lida a partir do índice:

mysql> explain format=json select foo, bar from test_dupe_key\G
*************************** 1. row ***************************
EXPLAIN: {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "1.60"
    },
    "table": {
      "table_name": "test_dupe_key",
      "access_type": "index",
      "key": "bar",
      "used_key_parts": [
        "bar",
        "foo"
      ],
      "key_length": "8",
      "rows_examined_per_scan": 3,
      "rows_produced_per_join": 3,
      "filtered": "100.00",
      "using_index": true,
      "cost_info": {
        "read_cost": "1.00",
        "eval_cost": "0.60",
        "prefix_cost": "1.60",
        "data_read_per_join": "48"
      },
      "used_columns": [
        "foo",
        "bar"
      ]
    }
  }
}
1 row in set, 1 warning (0.00 sec)

Isso mostra que a barra de teclas é usada e tem 2 partes de chave, ambas sendo lidas para produzir um comprimento de chave de 8 (2x4). Agora vamos mudar a chave composta para um único campo e verificar novamente:

mysql> alter table test_dupe_key drop key bar, add key(bar);
Query OK, 0 rows affected (0.12 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> explain format=json select foo, bar from test_dupe_key\G
*************************** 1. row ***************************
EXPLAIN: {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "1.60"
    },
    "table": {
      "table_name": "test_dupe_key",
      "access_type": "index",
      "key": "bar",
      "used_key_parts": [
        "bar"
      ],
      "key_length": "4",
      "rows_examined_per_scan": 3,
      "rows_produced_per_join": 3,
      "filtered": "100.00",
      "using_index": true,
      "cost_info": {
        "read_cost": "1.00",
        "eval_cost": "0.60",
        "prefix_cost": "1.60",
        "data_read_per_join": "48"
      },
      "used_columns": [
        "foo",
        "bar"
      ]
    }
  }
}
1 row in set, 1 warning (0.00 sec)

Apenas as partes principais e o comprimento agora mudam, o que é esperado, mas ainda é uma leitura de índice. Se transformarmos isso em uma consulta de intervalo no campo PK com uma restrição no campo indexado, vamos ver o que acontece:

mysql> explain format=json select foo, bar from test_dupe_key where bar = 1 and foo > 0\G
*************************** 1. row ***************************
EXPLAIN: {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "1.20"
    },
    "table": {
      "table_name": "test_dupe_key",
      "access_type": "range",
      "possible_keys": [
        "PRIMARY",
        "bar"
      ],
      "key": "bar",
      "used_key_parts": [
        "bar",
        "foo"
      ],
      "key_length": "8",
      "rows_examined_per_scan": 1,
      "rows_produced_per_join": 1,
      "filtered": "100.00",
      "using_index": true,
      "cost_info": {
        "read_cost": "1.00",
        "eval_cost": "0.20",
        "prefix_cost": "1.20",
        "data_read_per_join": "16"
      },
      "used_columns": [
        "foo",
        "bar"
      ],
      "attached_condition": "((`stack_204076`.`test_dupe_key`.`bar` = 1) and (`stack_204076`.`test_dupe_key`.`foo` > 0))"
    }
  }
}
1 row in set, 1 warning (0.00 sec)

O planejador de consulta considerou o PK para a consulta, mas escolheu o índice para bar, que agora tem uma mudança interessante em relação ao índice anterior lido, pois podemos ver que agora ele mostra como 2 partes principais novamente e um comprimento de 8:

  "key": "bar",
  "used_key_parts": [
    "bar",
    "foo"
  ],
  "key_length": "8"

Isso nos diz que o MySQL acessou o PK que está automaticamente contido no índice secundário