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

时间:2018-03-30 17:27:07

标签: mysql sql indexing database-indexes

我是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作为查找数据的索引,在这种情况下,revisadototalbusqueda列的基数是什么意思索引idx_compuesto1?为什么需要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

我希望你能帮助我更好地了解这些信息,谢谢。

1 个答案:

答案 0 :(得分:0)

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