哪些情况适合创建索引?
发布时间:2023-06-30 09:48:19 所属栏目:MySql教程 来源:
导读:这篇文章主要介绍了MySQL索引设计原则有哪些的相关知识,内容详细易懂,操作简单快捷,具有一定借鉴价值,相信大家阅读完这篇MySQL索引设计原则有哪些文章都会有所收获,下面我们一起来看看吧。
哪些情况适合创建
哪些情况适合创建
这篇文章主要介绍了MySQL索引设计原则有哪些的相关知识,内容详细易懂,操作简单快捷,具有一定借鉴价值,相信大家阅读完这篇MySQL索引设计原则有哪些文章都会有所收获,下面我们一起来看看吧。 哪些情况适合创建索引? 字段的数值有唯一性的限制。索引本身可以起到约束的作用,比如唯一索引,主键索引都是可以起到唯一性约束的,因此在我们的数据表中如果某个字段是唯一性的,就可以直接创建唯一性索引,或者主键索引。这样可以更快速地通过该索引来确定某条记录。 业务上具有唯一特性的字段,即使是组合字段,也必须建成唯一索引。 说明:不要以为唯一索引影响了 insert 速度,这个速度损耗可以忽略,但提高查找速度是明显的。 频繁作为 WHERE 查询条件的字段 某个字段在SELECT语句的 WHERE 条件中经常被使用到,那么就需要给这个字段创建索引了。尤其是在数据量大的情况下,创建普通索引就可以大幅提升数据查询的效率。 经常 GROUP BY 和 ORDER BY 的列 索引就是让数据按照某种顺序进行存储或检索,因此当我们使用 GROUP BY 对数据进行分组查询,或者使用 ORDER BY 对数据进行排序的时候,就需要对分组或者排序的字段进行索引。如果待排序的列有多个,那么可以在这些列上建立组合索引。 如果既有GROUP BY又有ORDER BY,可以考虑联合索引,由于GROUP BY先执行,联合索引中GROUP BY使用的字段排列在前面。 UPDATE、DELETE的WHERE条件列 当我们对某条数据进行UPDATE或者DELETE操作的时候,是否也需要对WHERE条件列创建索引呢? 对数据按照某个条件进行查询后再进行 UPDATE 或 DELETE 的操作,如果对 WHERE 字段创建了索引,就能大幅提升效率。原理是因为我们需要先根据 WHERE 条件列检索出来这条记录,然后再对它进行更新或删除。如果进行更新的时候,更新的字段是非索引字段,提升的效率会更明显,这是因为非索引字段更新不需要对索引进行维护。 DISTINCT字段需要创建索引 有时候我们需要对某个字段进行去重,使用 DISTINCT,那么对这个字段创建索引,也会提升查询效率。索引会对数据按照某种顺序进行排序,所以在去重的时候也会快很多。 多表 JOIN 连接操作时,创建索引注意事项 首先,连接表的数量尽量不要超过 3 张,因为每增加一张表就相当于增加了一次嵌套的循环,数量级增长会非常快,严重影响查询的效率。 其次,对 WHERE 条件创建索引,因为 WHERE 才是对数据条件的过滤。如果在数据量非常大的情况下,没有 WHERE 条件过滤是非常可怕的。 最后,对用于连接的字段创建索引,并且该字段在多张表中的类型必须一致。 使用列的类型小的创建索引 我们这里所说的类型大小指的就是该类型表示的数据范围的大小。 我们在定义表结构的时候要显式的指定列的类型,以整数类型为例,有TINYINT、MEDIUMINT、INT、BIGINT等,它们占用的存储空间依次递增,能表示的整数范围当然也是依次递增。如果我们想要对某个整数列建立索引的话,在表示的整数范围允许的情况下,尽量让索引列使用较小的类型,比如我们能使用INT就不要使用 BIGINT ,能使用 MEDIUMINT 就不要使用 INT。这是因为: 数据类型越小,在查询时进行的比较操作越快;数据类型越小,索引占用的存储空间就越少,在一个数据页内就可以放下更多的记录 ,从而减少磁盘 I/O 带来的性能损耗,也就意味着可以把更多的数据页缓存在内存中,从而加快读写效率。 这个建议对于表的主键来说更加适用 ,因为不仅是聚簇索引中会存储主键值,其他所有的二级索引的节点处都会存储一份记录的主键值,如果主键使用更小的数据类型,也就意味着节省更多的存储空间和更高效的I/O。 使用字符串前缀创建索引 假设我们的字符串很长,那存储一个字符串就需要占用很大的存储空间。在我们需要为这个字符串列建立索引时,那就意味着在对应的B+树中有这么两个问题: B+树索引中的记录需要把该列的完整字符串存储起来,更费时,而目字符串越长,在索引中占用的存储空间越大。如果B+树索引中索引列存储的字符串很长,那在做字符串比较时会占用更多的时间。 我们可以通过截取字段的前面一部分内容建立索引,这个就叫前缀索引。这样在查找记录时虽然不能精确的定位到记录的位置,但是能定位到相应前缀所在的位置,然后根据前缀相同的记录的主键值回表查询完整的字符串值。既节约空间,又减少了字符串的比较时间,还大体能解决排序的问题。 例如,TEXT和BLOG类型的字段,进行全文检索会很浪费时间,如果只检索字段前面的若干字符,这样可以提高检索速度。 示例:创建一张商户表,因为地址字段比较长,在地址字段上建立前缀索引 CREATE TABLE shop(address VARCHAR(120) NOT NULL); ALTER TABLE shop ADD INDEX idx_address(address(12)); 问题是,截取多少呢?截取得多了,达不到节省索引存储空间的目的;截取得少了,重复内容太多,字段的散列度(选择性)会降低。怎么计算不同的长度的选择性呢? 先看一下字段在全部数据中的选择度: SELECT COUNT(DISTINCT address) / COUNT(*) FROM shop; 通过不同长度去计算,与全表的选择性对比: 公式: COUNT(DISTINCT LEFT(列名, 索引长度)) / COUNT(*) 例如: SELECT COUNT(DISTINCT LEFT(address,10)) / COUNT(*) AS sub10, -- 截取前10个字符串的选择度 COUNT(DISTINCT LEFT(address,15)) / COUNT(*) AS sub15, -- 截取前15个字符串的选择度 COUNT(DISTINCT LEFT(address,20)) / COUNT(*) AS sub20, -- 截取前20个字符串的选择度 COUNT(DISTINCT LEFT(address,25)) / COUNT(*) AS sub25 -- 截取前25个字符串的选择度 FROM shop; 引申另一个问题:索引列前缀对排序的影响 如果使用了索引列前缀,比方说前边只把address列的 前12个字符 放到了二级索引中,下边这个查询可能就有点儿尴尬了: SELECT * FROM shop ORDER BY address LIMIT 10; 因为二级索引中不包含完整的address列信息,所以无法对前12个字符相同,后边的字符不同的记录进行排序,也就是使用索引列前缀的方式,无法支持使用索引排序,只能使用文件排序。 【强制】在 varchar 字段上建立索引时,必须指定索引长度,没必要对全字段建立索引,根据实际文本区分度决定索引长度。 说明:索引的长度与区分度是一对矛盾体,一般对字符串类型数据,长度为20的索引,区分度会高达 90%以上,可以使用COUNT(DISTINCT LEFT(列名, 索引长度)) / COUNT(*) 的区分度来确定。 关于“MySQL索引设计原则有哪些”这篇文章的内容就介绍到这里,感谢各位的阅读! (编辑:汽车网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
推荐文章
站长推荐