当使用复合索引时，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作为索引来查找数据，在本例中，revisado、total和busqueda列作为索引idx_compuesto1的一部分的基数是什么意思？以及为什么它采用idx_compuesto1而不是idx_compuesto2，我可以看到两个索引中的基数是不同的

这是查询explain的输出

*************************** 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一起使用。