【MySQL从入门到精通】【高级篇】(十)MyISAM的索引方案&&索引的优缺点

本文涉及的产品
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
RDS MySQL DuckDB 分析主实例,基础系列 4核8GB
RDS DuckDB + QuickBI 企业套餐,8核32GB + QuickBI 专业版
简介: 前面几篇文章介绍完了InnoDB存储引擎的索引方案,这篇文章接着来介绍下MyISAM存储引擎的索引方案。MyISAM和InnoDB存储引擎默认的索引都是B+Tree索引MyISAM引擎使用B+Tree作为索引结构,叶子节点的data域存放的是数据记录的地址。

1. 简介

前面几篇文章介绍完了InnoDB存储引擎的索引方案,这篇文章接着来介绍下MyISAM存储引擎的索引方案。

MyISAM和InnoDB存储引擎默认的索引都是B+Tree索引

MyISAM引擎使用B+Tree作为索引结构,叶子节点的data域存放的是数据记录的地址

2. 环境

环境 版本
Red Hat 4.8.5-39
MySQL 5.7

MyISAM的索引原理

通过前面的学习我们知道InnoDB引擎是索引即数据,也就是聚簇索引的叶子节点中已经把所有完整的用户记录都包含了,索引和数据都放在名为表名.ibd,例如使用InnoDB引擎的index_demo表的数据和索引存储在index_demo.ibd 中,

而MyISAM引擎是将索引和数据分开两个文件存储的,例如使用MyISAM引擎的engine_demo_table表的索引是存储在engine_demo_table.MYI文件中,数据是存储在engine_demo_table.MYD表中。

MyISAM的索引方案有如下特点:


将表中的记录按照记录的插入顺序单独存储在一个文件中,称之为数据文件。这个文件并不划分为若干个数据页,有多少记录就往这个文件中塞多少记录就成了。由于在插入数据的时候并没有刻意按照主键大小排序,所以我们并不能在这些数据上使用二分法进行查找。

使用MyISAM存储引擎的表会把索引信息另外存储到一个称为索引文件(表名.MYI)的另一个文件中,MyISAM会单独为表的主键创建一个索引,只不过在索引的叶子节点中存储的不是完整的用户记录,而是主键值+数据记录地址的组合。

这里一共有三列,假设我们以Col1为主键,上图是一个MyISAM表的主索引(Primary key)示意。可以看出MyISAM的索引文件仅仅保存数据记录的地址。在MyISAM中,主键索引和二级索引(Secondary key)在结构上没有任何区别。只是主键索引要求key是唯一的,而二级索引的key可以重复。

MyISAM与InnoDB的对比

MyISAM的索引方式都是"非聚簇"的,与InnoDB包含1个聚簇索引不同。这两种引擎的索引方式有如下不同之处:


在InnoDB存储引擎中,我们只需要根据主键值对聚簇索引进行一次查找就能找到对应的记录,而在MyISAM中却需要进行一次回表操作,意味着MyISAM中建立的索引相当于都是二级索引。

InnoDB的数据文件本身就是索引文件(索引即数据),而MyISAM索引文件和数据文件是分开的,索引文件仅保存数据记录的地址。

InnoDB的非聚簇索引data域存储相应记录主键的值,而MyISAM索引记录的是数据的地址。

MyISAM的回表操作十分快速,因为拿着地址偏移量直接到文件中取数据的,反观InnoDB回表是通过获取主键值到聚簇索引中去找用户记录,虽然说也不慢,但还是比不上直接用地址去访问。

InnoDB要求表必须有主键(MyISAM可以没有),如果没有显式指定主键,则MySQL系统会自动选择一个非空且唯一表示数据的列作为主键,如果不存在这种列,则MySQL自动为InnoDB表生成一个隐含字段作为主键,这个字段长度为6个字节,类型为长整型。

PS:

6. 不建议使用过长的字段作为主键,因为所有的二级索引都引用主键索引,过长的主键索引会使得二级索引变得过大,并且每个数据页大小是16KB,过长的主键索引会导致每个数据页存储的数据变少。

7. 用非单调的字段作为主键在InnoDB中不是一个好主意,因为InnoDB数据文件本身是一块B+Tree,非单调的主键会造成插入新记录时,数据文件为了维持B+Tree的特性而频繁的分裂调整。十分低效,而使用自增字段作为主键则是一个很好的选择。

索引的优点

索引可以大大提高数据检索的效率,降低数据库的IO成本

通过创建唯一索引,可以保证数据库表中每一行数据的唯一性。

在实现数据的参考完整性方面,可以加速表和表之间的连接,换句话说,对于有依赖关系的子表和父表联合查询时,可以提高查询速度。

在使用分组和排序子句进行数据查询时,可以显著减少查询中分组和排序的时间,降低CPU的消耗

索引的缺点

空间上的代价

每建立一个索引都有为它建立一棵B+树,每一棵B+树的每一个节点都是一个数据页,一个数据页默认占用16KB的存储空间,一棵很大的B+树由很多数据页组成,那就是很大的一片存储空间。

时间上的代价

每次对表中的数据进行增、删、改操作时,都需要去修改各个B+树索引。而我们呢讲过B+树每次节点都是按照索引列的值从小到大的顺序排序而组成了双向链表。无论是叶子节点中的记录,还是内节点中的记录都是按照索引列的值从小到大的顺序而形成了一个单向链表。而增、删、改操作可能会对节点和记录的排序造成破坏,所以存储引擎需要额外的时间进行一些记录移位,页面分裂,页面回收等操作来维护节点和记录的排序。如果我们建立了许多索引,每个索引对应的B+树都要进行相应的维护操作,会给性能拖后腿。

总结

本文详细介绍MyISAM的索引方案,MyISAM引擎和InnoDB引擎默认使用的索引都是B+Tree索引,他们之间的不同之处是MyISAM的索引和数据是分开的,索引的叶子节点只会存储数据的地址,查找数据时需要回表操作,而InnoDB引擎的索引即数据,聚簇索引的叶子节点存储的是完整用户记录。


相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
10月前
|
存储 SQL 关系型数据库
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
|
8月前
|
运维 监控 关系型数据库
MySQL高可用方案:MHA与Galera Cluster对比
本文深入对比了MySQL高可用方案MHA与Galera Cluster的架构原理及适用场景。MHA适用于读写分离、集中写入的场景,具备高效写性能与简单运维优势;而Galera Cluster提供强一致性与多主写入能力,适合对数据一致性要求严格的业务。通过架构对比、性能分析及运维复杂度评估,帮助读者根据自身业务需求选择最合适的高可用方案。
|
10月前
|
存储 关系型数据库 MySQL
MySQL数据库索引的数据结构?
MySQL中默认使用B+tree索引,它是一种多路平衡搜索树,具有树高较低、检索速度快的特点。所有数据存储在叶子节点,非叶子节点仅作索引,且叶子节点形成双向链表,便于区间查询。
258 4
|
9月前
|
存储 关系型数据库 MySQL
修复.net Framework4.x连接MYSQL时遇到utf8mb3字符集不支持错误方案。
通过上述步骤大多数情况下能够解决由于UTF-encoding相关错误所带来影响,在实施过程当中要注意备份重要信息以防止意外发生造成无法挽回损失,并且逐一排查确认具体原因以采取针对性措施解除障碍。
602 12
|
10月前
|
SQL 关系型数据库 MySQL
解决MySQL "ONLY_FULL_GROUP_BY" 错误的方案
在实际操作中,应优先考虑修正查询,使之符合 `ONLY_FULL_GROUP_BY`模式的要求,从而既保持了查询的准确性,也避免了潜在的不一致和难以预测的结果。只有在完全理解查询的业务逻辑及其后果,并且需要临时解决问题的情况下,才选择修改SQL模式或使用 `ANY_VALUE()`等方法作为短期解决方案。
983 8
|
10月前
|
存储 SQL 关系型数据库
MySQL 核心知识与索引优化全解析
本文系统梳理了 MySQL 的核心知识与索引优化策略。在基础概念部分,阐述了 char 与 varchar 在存储方式和性能上的差异,以及事务的 ACID 特性、并发事务问题及对应的隔离级别(MySQL 默认 REPEATABLE READ)。 索引基础部分,详解了 InnoDB 默认的 B+tree 索引结构(多路平衡树、叶子节点存数据、双向链表支持区间查询),区分了聚簇索引(数据与索引共存,唯一)和二级索引(数据与索引分离,多个),解释了回表查询的概念及优化方法,并分析了 B+tree 作为索引结构的优势(树高低、效率稳、支持区间查询)。 索引优化部分,列出了索引创建的六大原则
252 2
|
9月前
|
监控 NoSQL 关系型数据库
保障Redis与MySQL数据一致性的强化方案
在设计时,需要充分考虑到业务场景和系统复杂度,避免为了追求一致性而过度牺牲系统性能。保持简洁但有效的策略往往比采取过于复杂的方案更加实际。同时,各种方案都需要在实际业务场景中经过慎重评估和充分测试才可以投入生产环境。
458 0
|
11月前
|
存储 关系型数据库 MySQL
MySQL覆盖索引解释
总之,覆盖索引就像是图书馆中那些使得搜索变得极为迅速和简单的工具,一旦正确使用,就会让你的数据库查询飞快而轻便。让数据检索就像是读者在图书目录中以最快速度找到所需信息一样简便。这样的效率和速度,让覆盖索引成为数据库优化师傅们手中的尚方宝剑,既能够提升性能,又能够保持系统的整洁高效。
329 9
|
12月前
|
机器学习/深度学习 关系型数据库 MySQL
对比MySQL全文索引与常规索引的互异性
现在,你或许明白了这两种索引的差异,但任何技术决策都不应仅仅基于理论之上。你可以创建你的数据库实验环境,尝试不同类型的索引,看看它们如何影响性能,感受它们真实的力量。只有这样,你才能熟悉它们,掌握什么时候使用全文索引,什么时候使用常规索引,以适应复杂多变的业务需求。
299 12
|
10月前
|
关系型数据库 MySQL Java
MySQL 分库分表 + 平滑扩容方案 (秒懂+史上最全)
MySQL 分库分表 + 平滑扩容方案 (秒懂+史上最全)

推荐镜像

更多