【问题标题】:What is cardinality in MySQL?MySQL中的基数是什么?
【发布时间】:2011-02-03 16:54:44
【问题描述】:

什么是 MySQL 中的基数?请用简单的非技术语言解释。

如果任何表的索引详细信息显示字段的基数,例如 group_id 为 11,那么这是什么意思?

【问题讨论】:

    标签: mysql indexing


    【解决方案1】:

    最大基数:所有值都是唯一的

    最小基数:所有值都相同

    某些列被称为高基数列,因为它们具有适当的约束(如唯一),禁止您在每一行中放置相同的值。

    基数是一种影响对数据进行聚类、排序和搜索能力的属性。因此,它是数据库中查询计划者的重要衡量标准,是他们可以用来选择最佳计划的启发式方法。

    【讨论】:

    • 这种对大词的迷恋是怎么回事。 “独特性”会很好用不是吗?
    • @Pacerier:是的,虽然我认为从事数据库工作的人已经非常熟悉关系理论、集合论和数学。他们从集合论中借用了这个术语:en.m.wikipedia.org/wiki/Cardinality
    • @Pacerier,区别是一个更大的词(1)
    • @Drew, ;) 如果比较词位,则不是。
    • @Pacerier Lexeme? “独特性”也可以在那里工作,不是吗? ;) 如果我们足够努力,我们可以将整个语言减少到只有 1 个单词,并通过不同的重复和停顿来表达自己。
    【解决方案2】:

    维基百科对cardinality in SQL的总结如下:

    SQL(结构化查询语言)中,术语基数是指databasetable的特定列(属性)中包含的数据值的uniqueness。基数越低,列中的重复元素就越多。因此,具有最低可能基数的列对于每一行将具有相同的值。 SQL 数据库使用基数来帮助确定给定查询的最佳 query plan

    【讨论】:

      【解决方案3】:

      它是对索引中唯一值数量的估计。

      对于具有单个主键列的表,基数通常应等于表中的行数。

      More information.

      【讨论】:

      • 应该是“将永远等于...”而不是“通常应该等于...”!
      【解决方案4】:

      根据 Kami 链接的 Wikipedia 文章,它基本上与列值的唯一性程度有关。

      为什么重要的是要考虑它会影响索引策略。索引只有 2 个可能值的低基数列几乎没有意义,因为索引的选择性不足以使用。

      【讨论】:

      • 第二段很重要,如果您尝试了解何时对列进行索引是有意义的。
      【解决方案5】:

      基数越高,行的区分就越好。差异化有助于导航更少的分支来获取数据。

      因此更高的基数值意味着:

      • 更好的读取查询性能;
      • 更大的数据库大小;
      • 写查询的性能更差,因为隐藏的索引数据正在更新。

      【讨论】:

      • 不明白为什么应该“写查询的性能更差,因为隐藏的索引数据正在更新。”?
      • 是的。需要做更多的工作来同步。
      【解决方案6】:

      在数学术语中,基数是一组值中值的计数。一个集合只能包含唯一值。 一个例子是集合“A”。

      令集合“A”为:A={1,2,3} - 该集合的基数为 |3|。

      如果设置“A”包含 5 个值 A={10,21,33,42,57},则基数为 |5|。

      SET     VALUES           Cardinality
      A       1,2,3                 3
      B       10,21,33,42,57        5
      

      这在 MySQL 的上下文中意味着表列的基数是该列唯一值的计数。如果您正在查看主键列的基数(例如 table.id),那么该列的基数将告诉您该表包含多少行,因为表中的每一行都有一个唯一 ID。 您不必对该表执行“COUNT(*)”来找出它有多少行,只需查看基数即可。

      【讨论】:

        【解决方案7】:

        简单来说,基数是表中的行数或元组数。列数称为“度”

        【讨论】:

        • 不正确 - 您可能有数百万行和 1 的基数(所有值都相同)或数百万(如果每个行值都是唯一的,则最多为表中的行数)!
        【解决方案8】:

        来自manual

        基数

        对索引中唯一值数量的估计。这是 通过运行 ANALYZE TABLE 或 myisamchk -a 更新。基数是 根据存储为整数的统计信息进行计数,因此该值不是 即使对于小桌子也必须准确。基数越高, MySQL 在进行连接时使用索引的机会越大。

        还有一个analysis from Percona

        CREATE TABLE `antest` (
          `i` int(10) unsigned NOT NULL,
          `c` char(80) default NULL,
          KEY `i` (`i`),
          KEY `c` (`c`,`i`)
        ) ENGINE=MyISAM DEFAULT CHARSET=latin1
        
        mysql> select count(distinct c) from antest;
        +-------------------+
        | count(distinct c) |
        +-------------------+
        |               101 |
        +-------------------+
        1 row in set (0.36 sec)
        
        
        mysql> select count(distinct i) from antest;
        +-------------------+
        | count(distinct i) |
        +-------------------+
        |               101 |
        +-------------------+
        1 row in set (0.20 sec)
        
        mysql> select count(distinct i,c) from antest;
        +---------------------+
        | count(distinct i,c) |
        +---------------------+
        |               10201 |
        +---------------------+
        1 row in set (0.43 sec)
        
        mysql> show index from antest;
        +--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
        | Table  | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
        +--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
        | antest |          1 | i        |            1 | i           | A         |        NULL |     NULL | NULL   |      | BTREE      |         |
        | antest |          1 | c        |            1 | c           | A         |        NULL |     NULL | NULL   | YES  | BTREE      |         |
        | antest |          1 | c        |            2 | i           | A         |        NULL |     NULL | NULL   |      | BTREE      |         |
        +--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
        3 rows in set (0.00 sec)
        
        mysql> analyze table sys_users;
        +--------------------------------+---------+----------+----------+
        | Table                          | Op      | Msg_type | Msg_text |
        +--------------------------------+---------+----------+----------+
        | antest                         | analyze | status   | OK       |
        +--------------------------------+---------+----------+----------+
        1 row in set (0.01 sec)
        
        
        mysql> show index from antest;
        +--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
        | Table  | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
        +--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
        | antest |          1 | i        |            1 | i           | A         |         101 |     NULL | NULL   |      | BTREE      |         |
        | antest |          1 | c        |            1 | c           | A         |         101 |     NULL | NULL   | YES  | BTREE      |         |
        | antest |          1 | c        |            2 | i           | A         |       10240 |     NULL | NULL   |      | BTREE      |         |
        +--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
        3 rows in set (0.01 sec)
        

        【讨论】:

        • 此答案包含您自己编写的零内容,它只是 MySQL 手册和您链接到的博客文章的拼贴。并且在此之上进行了可怕的格式化。
        • 现在它清楚地说明了来源并且格式更好。
        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2012-05-24
        • 1970-01-01
        • 2018-09-09
        • 1970-01-01
        • 1970-01-01
        • 2012-10-07
        相关资源
        最近更新 更多