为什么添加新索引时，MySQL中索引的基数保持不变？ [英] Why does the cardinality of an index in MySQL remain unchanged when I add a new index?

问题描述

  ALTER TABLE成员ADD FULLTEXT（about ，FNAME，L-NAME，JOB_TITLE）; 
  

问题在于，使用 phpmyadmin 我可以看到新的基数索引仅为 1 。这是否意味着索引将永远不会被使用？

我运行了分析表命令，但它似乎没有做任何事情。

 分析表格成员
  

索引字段的类型是varchar（100），varchar（100），text，varchar（200），引擎使用的是MyISAM，表中有大约30,000行，都是唯一的。我的MySQL版本是5.0.45。

我做错了什么？

解决方案

如果表中只有1行，那么索引的基数当然应该是1。它只是计算唯一值的数量。

如果您将索引视为基于桶的查找表（如哈希），那么基数就是桶的数量。

以下是它的工作原理：当您在一组列（a，b，c，d）上构建索引时，数据库遍历表中的所有行，查看每行的这4列的有序四元组。假设您的表格如下所示：

  abcde 
  -   -   -   -   -  
 1 1 1 1 200 
 1 1 1 1 300 
 1 2 1 1 200 
 1 3 1 1 200 
 $ / code> 

所以数据库看起来就是4列（a，b，c，d）：
$ b $

  abcd 
  -   -   -   -  
 1 1 1 1 
 1 2 1 1 
 1 3 1 1 
  

看到只剩下3个唯一的行了吗？那些将成为我们的桶，但我们会回到那个。实际上，表格中的每一行也都有记录标识或行标识符。所以我们原来的表格如下所示：



 （row id）abcde 
 --------  -  -   -   -   -   -  
 00000001 1 1 1 1 200 
 00000002 1 1 1 1 300 
 00000003 1 2 1 1 200 
 00000004 1 3 1 1 200 
 $ / code> 

因此，当我们只查看（a，b，c，d）的4列时，还真的看着行号：

 （行ID）abcd 
 -------- -   -   -   -  
 00000001 1 1 1 1 
 00000002 1 1 1 1 
 00000003 1 2 1 1 
 00000004 1 3 1 1 
  

但我们希望通过（a，b，c，d）进行查找，而不是通过行id进行查找，因此我们生成了类似这：



 （a，b，c，d）（row id）
 ------- -  -------- 
 1,1,1,1 00000001 
 1,1,1,1 00000002 
 1,2,1,1 00000003 
 1,3,1,1 00000004 
  

最后，我们将所有行ID （a，b，c，d）值：



 （a，b，c，d， d）（行ID）
 --------- --------------------- 
 1,1,1， 1 00000001和00000002 
 1,2,1,1 00000003 
 1,3,1,1 00000004 
  

看到了吗？ （1,1,1,1）（1,2,1,1）和（1,3,1,1）的值（a，b，c，d）已成为我们查找表的关键到原始表格的行。

其实，这些都不是真的发生，但它应该给你一个很好的想法，如何天真（即简单）可以完成索引的实现。

但底线是：基数只是衡量索引中有多少个唯一行。在我们的例子中，我们查找表中的键数是3。

希望有帮助！

I have added a FULLTEXT index to one of my MySQL database tables as follows:

ALTER TABLE members ADD FULLTEXT(about,fname,lname,job_title);

The problem is that using phpmyadmin I can see the cardinality of my new index is only 1. Does this mean the index will never be used?

I have run a analyze table command but it didn't seem to do anything.

analyze table members

The respective types of the index fields are varchar(100), varchar(100), text, varchar(200) and the engine used is MyISAM and the table has about 30,000 rows, all unique. My MySQL version is 5.0.45.

Am I doing something wrong?

解决方案

If you only have 1 row in the table, the cardinality for the index should be 1, of course. It's just counting the number of unique values.

If you think of an index as a lookup-table based on buckets (like a hash), then the cardinality is the number of buckets.

Here's how it works: When you build an index over a set of columns (a,b,c,d), then the database goes over all the rows in the table, looking at the ordered quadruplets of those 4 columns, for each row. Let's say your table looks like this:

a  b  c  d  e   
-- -- -- -- --  
1  1  1  1  200 
1  1  1  1  300
1  2  1  1  200
1  3  1  1  200

So what the database looks at is just the 4 columns (a,b,c,d):

a  b  c  d  
-- -- -- --
1  1  1  1 
1  2  1  1 
1  3  1  1 

See that there are only 3 unique rows left? Those will become our buckets, but we'll get back to that. In reality, there's also a record id, or row identifier for each row in the table. So our original table looks like this:

(row id) a  b  c  d  e   
-------- -- -- -- -- --  
00000001 1  1  1  1  200 
00000002 1  1  1  1  300
00000003 1  2  1  1  200
00000004 1  3  1  1  200

So when we look at only the 4 columns of (a,b,c,d), we're really looking also at the row id:

(row id) a  b  c  d 
-------- -- -- -- --
00000001 1  1  1  1
00000002 1  1  1  1
00000003 1  2  1  1
00000004 1  3  1  1

But we want to do lookup by (a,b,c,d) and not by row id, so we produce something like this:

(a,b,c,d) (row id)
--------- --------
1,1,1,1   00000001
1,1,1,1   00000002
1,2,1,1   00000003
1,3,1,1   00000004

And finally, we group all the row ids of rows that have identicle (a,b,c,d) values together:

(a,b,c,d) (row id)
--------- ---------------------
1,1,1,1   00000001 and 00000002
1,2,1,1   00000003
1,3,1,1   00000004

See that? The values of (a,b,c,d), which are (1,1,1,1) (1,2,1,1) and (1,3,1,1) have become keys for our lookup table into the rows of the original table.

Actually, none of this really happens, but it should give you a good idea on how a "naive" (i.e. straight-forward) implementation of an index might be done.

But the bottom line is this: cardinality just measures how many unique rows there are in an index. And in our example that was the number of keys in our lookup table, which was 3.

Hope that helps!

这篇关于为什么添加新索引时，MySQL中索引的基数保持不变？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！