目录
一、存储引擎
1.1 MySQL体系结构
- 连接层
最上层是一些客户端和链接服务,主要完成一些类似于连接处理、授权认证、及相关的安全方案。服务器也会为安全接入的每个客户端验证它所具有的操作权限
- 服务层
第二层架构主要完成带动书的核心服务功能,如SQL接口,并完成缓存的查询、SQL的分析和优化,部分内置函数的执行。所有跨存储引擎的功能也在这一层实现,如 过程、函数等
- 引擎层
存储引擎真正的负责了MySQL中数据的存储和提取,服务器通过API和存储引擎进行通信。不同的存储引擎具有不同的功能,这样可以根据自己的需要,来选取合适的存储引擎
- 存储层
主要是将数据存储在文件系统之上,并完成与存储引擎的交互
1.2 存储引擎介绍
存储引擎就是存储数据、建立索引、更新/查询数据等技术的实现方式。存储引擎是基于表的,而不是基于库的,所以存储引擎也可被称为表类型
1.3 存储引擎特点
1.3.1 InnoDB
- 介绍
InnoDB是一种兼顾高可靠性和高性能的通用存储引擎,在MySQL5.5之后,InnoDB是默认的MySQL存储引擎
- 特点
DML操作存储ACID模型,支持事务;
行级锁,提高并发访问性能;
支持外键FOREIGN KEY约束,保证数据的完整性和正确性
- 文件
xxx.ibd:xxx代表的表名,InnoDB引擎的每张表都会对应这样的一个表空间文件,存储该表的表结构(frm、sdi)、数据和索引。 参数:innodb_file_per_table
1.3.2 MyISAM
- 介绍
MyISAM是MySQL早期的默认存储引擎
- 特点
不支持事务,不支持外键
支持表锁,不支持行锁
访问速度快
- 文件
xxx.sdi:存储表结构信息
xxx.MYD:存储数据
xxx.MYI:存储索引
1.3.3 Memory
- 介绍
Memory引擎的表数据时存储在内存中的,由于受到硬件问题或断电问题的影响,只能将这些表作为临时表或存储使用
- 特点
内存存放
hash索引(默认)
- 文件
xxx.sdi:存储表结构信息
1.4 存储引擎选择
在选择存储引擎时,应该根据应用系统的特点选择合适的存储引擎。对于复杂的应用系统,还可以根据实际情况选择多种存储引擎进行组合。
- InnoDB:是MySQL的默认存储引擎,支持事务、外键。如果应用对事务的完整性有比较高的要求,在并发条件下要求数据的一致性,数据操作除了插入和查询之外,还包括很多的更新、删除操作,那么InnoDB存储引擎是比较合适的选择
- MyISAM:如果应用是以读操作和插入操作为主,只有很少的更新和删除操作,并且对事务的完整性、并发性要求不是很高,那么选择这个存储引擎是非常合适的
- Memory:将所有数据保存在内存中,访问速度快,通常用于临时表及缓存。Memory的缺陷就是对表的大小有限制,太大的表无法存储在内存中,而且无法保证数据的安全性
二、索引
2.1 索引概述
索引时帮助MySQL高效获取数据的数据结构(有序)。在数据之外,数据库系统还维护着满足特定查找算法的数据结构,这些数据结构以某种方式引用(指向)数据,这样就可以在这些数据结构中上实现高级查找算法,这种数据结构就是索引。
索引的优缺点
优点:
- 提高数据检索的效率,降低数据库的IO成本
- 通过索引列队数据进行排序,降低数据排序的成本,降低CPU的消耗
缺点
- 索引列也是要占用空间的
- 索引大大提高了查询效率,同时却也降低更新表的速度,如对表进行INSERT、UPDATE、DELETE时,效率降低
2.2 索引结构
2.2.1 二叉树
2.2.2 B-Tree(多路平衡查找树)
2.2.3 B+Tree
相对于B-Tree区别:
- 所有的数据都会出现在叶子节点
- 叶子节点形成一个单向链表
MySQL索引数据结构对经典的B+Tree进行了优化。在原B+Tree的基础上,增加了一个指向相邻叶子节点的链表指针,就形成了带有顺序指针的B+Tree,提高区间访问的性能
2.2.4 Hash
哈希索引就是采用一定的hash算法,将键值换算成新的hash值,映射到对应的槽位上,然后存储在hash表中
Hash索引特点
- Hash索引只能用于对等比较(=,in),不支持范围查询(between,>,<,...)
- 无法利用索引完成排序操作
- 查询效率高,通常只需要一次检索就可以了,效率通常要高于B+Tree索引
存储引擎支持
在MySQL中,支持hash索引的是Memory引擎,而InnoDB种具有自适应的hash功能,hash索引是存储引擎根据B+Tree索引在指定条件下自动构建的
2.3 索引分类
2.4 索引语法
2.5 SQL性能分析
2.5.1 SQL执行频率
2.5.2 慢查询日志
2.5.3 profile详情
2.5.4 explain执行计划
EXPLAIN执行计划各字段含义:
字段 含义 id select查询序列号,表示查询中执行select子句或者是操作表的顺序(id相同,执行顺序从上到下;id不同,值越大,越先执行) select_type 表示SELECT的类型,常见的取值有SIMPLE(简单表,即不适用表连接或者子查询),PRIMARY(主查询,即外层的查询)、UNION(UNION中的第二个或者后面的查询语句)、SUBQUERY(SELECT/WHERE之后包含了子查询)等
type 表示连接类型,性能由好到差的连接类型为NULL、system、const、eq_ref、ref、range、index、all possible_key 显示可能应用在这张表上的索引,一个或多个 key 实际使用的索引,如果为NULL,则没有使用索引 key_len 表示索引中使用的字节数,该值为索引字段最大可能长度,并非实际使用长度,在不损失精度性的前提下,长度越短越好 rows MySQL认为必须要执行查询的行数,在innodb引擎的表中,是一个估计值,可能并不总是准确的 filtered 表示返回结果的行数占需读取行数的百分比,filtered的值越大越好
2.6 索引使用
2.6.1 验证索引效率
2.6.2 最左前缀法则
如果索引了多列(联合索引),要遵守最左前缀法则。最左前缀法则指的是查询从索引的最左列开始,并且不跳过索引中的列。如果跳跃某一列,索引将部分失效(后面的字段索引失效)
2.6.3 范围查询
联合索引中,出现范围查询(>,<),范围查询右侧的列索引失效
2.6.4 索引失效情况
- 索引列运算
不要在索引列上进行运算操作,索引将失效
- 字符串不加引号
字符串类型字段使用时,不加引号,索引将失效
- 模糊查询
如果仅仅是尾部模糊匹配,索引不会失效。如果使头部模糊匹配,索引将失效
- or连接条件
用or分隔开的条件,如果or前的条件中的列有索引,而后面的列中没有索引,那么涉及的索引都不会被用到
- 数据分布影响
如果MySQL评估使用索引比全表更慢,则不使用索引
2.6.5 SQL提示
2.6.6 覆盖索引
尽量使用覆盖索引(查询使用了索引,并且需要返回的列,在该索引中已经全部能够找到),减少select *
2.6.7 前缀索引
当字段类型为字符串(varchar,text,longtext等)时,有时候需要索引很长的字符串,这会让索引变得很大,在查询时浪费大量的磁盘IO,影响查询效率。此时可以只将字符串的一部分前缀,建立索引,这样可以大大节约索引空间,从而提高索引效率
2.6.8 单列索引与联合索引
2.7 索引设计原则
- 针对于数据量较大,且查询比较频繁的表建立索引
- 针对于常作为查询条件(where)、排序(order by)、分组(group by)操作的字段建立索引
- 尽量选择区分度高的列作为索引,尽量建立唯一索引,区分度越高,使用索引的效率越高
- 如果使字符串类型的字段,字段的长度较长,可以针对于字段的特点,建立前缀索引
- 尽量使用联合索引,减少单列索引,查询时,联合索引很多时候可以覆盖索引,节省存储空间,避免回表,提高查询效率.
- 要控制索引的数量,索引并不是越多越好,索引越多,维护索引结构的代价也就越大,会影响增删改的效率
- 如果索引列不能存储NULL值,请在创建表时使用NOT NULL约束它,当优化器知道每列是否包含NULL值时,它可以更好地确定哪个索引最有效的用于查询
2.8 总结
转载:https://blog.csdn.net/weixin_61843013/article/details/127595713