使用复合索引时 MySQL 中的基数是什么意思？

Question

我是 mysql 新手，对基数的含义有点困惑，我读到它表示数字或唯一行，但我想知道在这种情况下它是什么意思，这是我的表定义

+-------------------+--------------+------+-----+---------+----------------+
| Field             | Type         | Null | Key | Default | Extra          |
+-------------------+--------------+------+-----+---------+----------------+
| id                | int(11)      | NO   | PRI | NULL    | auto_increment |
| revisado          | varchar(10)  | YES  | MUL | NULL    |                |
| total             | int(11)      | NO   | MUL | NULL    |                |
| busqueda          | varchar(300) | NO   | MUL | NULL    |                |
| clave             | bigint(15)   | NO   |     | NULL    |                |
| producto_servicio | varchar(300) | NO   |     | NULL    |                |
+-------------------+--------------+------+-----+---------+----------------+

目前的记录总数是 13621

我有这个问题

SELECT clave, producto_servicio FROM buscador_claves2 WHERE busqueda = 'FERRETERIA' AND total = 2 AND revisado = 'APROBADO'

这是表的索引定义

+------------------+------------+----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table            | Non_unique | Key_name       | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+------------------+------------+----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| buscador_claves2 |          0 | PRIMARY        |            1 | id          | A         |       14309 |     NULL | NULL   |      | BTREE      |         |
| buscador_claves2 |          1 | idx_busqueda   |            1 | busqueda    | A         |       14309 |      255 | NULL   |      | BTREE      |         |
| buscador_claves2 |          1 | idx_total      |            1 | total       | A         |           3 |     NULL | NULL   |      | BTREE      |         |
| buscador_claves2 |          1 | idx_revisado   |            1 | revisado    | A         |           1 |     NULL | NULL   | YES  | BTREE      |         |
| buscador_claves2 |          1 | idx_compuesto1 |            1 | revisado    | A         |           1 |     NULL | NULL   | YES  | BTREE      |         |
| buscador_claves2 |          1 | idx_compuesto1 |            2 | total       | A         |         105 |     NULL | NULL   |      | BTREE      |         |
| buscador_claves2 |          1 | idx_compuesto1 |            3 | busqueda    | A         |       14309 |      255 | NULL   |      | BTREE      |         |
| buscador_claves2 |          1 | idx_compuesto2 |            1 | busqueda    | A         |       14309 |      255 | NULL   |      | BTREE      |         |
| buscador_claves2 |          1 | idx_compuesto2 |            2 | total       | A         |       14309 |     NULL | NULL   |      | BTREE      |         |
| buscador_claves2 |          1 | idx_compuesto2 |            3 | revisado    | A         |       14309 |     NULL | NULL   | YES  | BTREE      |         |
+------------------+------------+----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+

查询以idx_compuesto1 作为索引来查找数据，在这种情况下，作为索引idx_compuesto1 一部分的revisado、total 和busqueda 列的基数是什么意思？以及为什么需要idx_compuesto1 而不是idx_compuesto2，我可以看到两个索引的基数不同

这是查询解释的输出

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: buscador_claves2
         type: ref
possible_keys: idx_busqueda,idx_total,idx_revisado,idx_compuesto1,idx_compuesto2
          key: idx_compuesto1
      key_len: 804
          ref: const,const,const
         rows: 1
        Extra: Using where

希望您能帮助我更好地理解这些信息，谢谢。

Answer 1

在 MySQL 中，索引基数列的值是存储引擎对该索引中唯一值数量的估计。它用于确定此索引在连接期间的使用情况。通常 MySQL 优化器更喜欢具有更高基数的索引，因为这通常意味着它能够过滤到更少的行。理想的情况是基数的值始终等于SELECT COUNT(DISTINCT the_key)...，但在实践中，由于在正常数据库操作期间难以以不中断的有效方式准确计算这一点，它通常会偏离一些相对较小的余量数据库性能。 ANALYZE TABLE 之后的值会更准确。当优化器可以为特定连接选择多个键时，关闭基数开始变得重要，选择哪个键会在性能上产生巨大差异，并且这些键的基数估计值足以导致优化器选择错误的钥匙。这些情况相对较少，但确实会发生。在这种情况下，可以使用 ANALYZE TABLE 或 - 如果您始终 100% 确定哪个键更适合连接 - 可以通过显式使优化器在查询中将其与 FORCE KEY 一起使用来解决问题。