gpt4 book ai didi

mysql - 为什么在MySQL中添加新索引时,索引的基数没有变化?

转载 作者:可可西里 更新时间:2023-11-01 06:27:28 24 4
gpt4 key购买 nike

我已将 FULLTEXT 索引添加到我的 MySQL 数据库表之一,如下所示:

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

问题是使用 phpmyadmin 我可以看到我的新索引的基数仅为 1。这是否意味着永远不会使用该索引?

我已经运行了一个分析表命令,但它似乎没有做任何事情。

analyze table members

索引字段的类型分别为varchar(100)、varchar(100)、text、varchar(200),使用的引擎是MyISAM,表大约有30000行,都是唯一的。我的 MySQL 版本是 5.0.45。

我做错了什么吗?

最佳答案

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

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

工作原理如下:当您在一组列 (a,b,c,d) 上建立索引时,数据库会遍历表中的所有行,查看对于每一行,这 4 列的有序四元组。假设您的表格如下所示:

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

所以数据库只查看 4 列 (a,b,c,d):

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

看到只剩下 3 个不同的行了吗?那些将成为我们的桶,但我们会回到那个。实际上,表中的每一行还有一个记录 ID 或行标识符。所以我们原来的表是这样的:

(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

所以当我们只查看 (a,b,c,d) 的 4 列时,我们实际上也在查看行 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

但我们想通过 (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

最后,我们将具有相同 (a,b,c,d) 值的行的所有行 ID 分组在一起:

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

看到了吗? (a,b,c,d) 的值,即 (1,1,1,1) (1,2,1,1) 和 (1,3,1,1) 已成为我们查找表的键放入原始表格的行中。

实际上,这一切都没有真正发生,但它应该让您了解如何完成索引的“天真”(即直接)实现。

但最重要的是:基数只是衡量一个索引中有多少唯一行。在我们的示例中,这是查找表中的键数,即 3。

希望对您有所帮助!

关于mysql - 为什么在MySQL中添加新索引时,索引的基数没有变化?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/755569/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com