MySQL数据库进阶篇一(存储引擎、索引)

目录

一、存储引擎

1.1、MySQL体系结构:连接层,Server层,引擎层,存储层

  • 连接层:连接层负责处理客户端与MySQL服务器之间的连接和通信。它接收客户端的连接请求,并建立与客户端的网络连接。
  • Server层:包括连接器、查询缓存、分析器、优化器、执行器等,涵盖 MySQL 的大多数核心服务功能,以及所有的内置函数(如日期、时间、数学和加密函数等),所有跨存储引擎的功能都在这一层实现,比如存储过程、触发器、视图等。
  • 引擎层:负责数据的存储和检索。架构模式是插件式,服务器通过API和存储引擎进行通信。支持 InnoDB、MyISAM、Memory 等多个存储引擎。
  • 存储层:MYSQL的物理存储部分,负责将数据(如: redolog、undolog、数据、索引、二进制日志、错误日志、查询 日志、慢查询日志等)存储在磁盘上。

1.2、存储引擎

存储引擎是存储数据、建立索引、更新/查询数据等技术的实现方式 。存储引擎是基于表的,而不是基于库的,所以存储引擎也可被称为表类型。可以在创建表的时指定选择的存储引擎,没有指定将自动选择默认的存储引擎。

  • 存储引擎的查看和指定
    • 使用show create table 表名; 查看建表语句,可以看到当前表所使用的存储引擎
    • 在创建表时,指定存储引擎
    • 查询当前数据库支持的存储引擎 show engines;
sql 复制代码
CREATE TABLE 表名(
字段1 字段1类型 [ COMMENT 字段1注释 ] ,
......
字段n 字段n类型 [COMMENT 字段n注释 ]
) ENGINE = INNODB [ COMMENT 表注释 ] ;

1.2.1、存储引擎:InnoDB(MySQL 5.5后默认的存储引擎)

特点:

  • DML操作遵循ACID模型,支持事务
  • 行级锁,提高并发访问性能;
  • 支持外键FOREIGN KEY约束,保证数据的完整性和正确性;

文件:

  • xxx.ibd 存储表结构(frm-早期的 、sdi-新版的)、数据和索引
    xxx是表名,innoDB引擎每张表都会对应一个表空间文件
  • show variables like 'innodb_file_per_table'; 参数代表是否时一张表对应一个文件。MySQL 8.0 版本以后默认打开

    逻辑存储结构:
    表空间->段->区->页->行
    一区可以有64个连续的页

1.2.2、存储引擎:MyISAM (MySQL早期默认存储引擎)

特点:

  • 不支持事务,不支持外键
  • 支持表锁,不支持行锁
  • 优点:更少的存储空间,支持全文索引,适用于读取频率较高、写入频率较低的应用场景

文件:

  • xxx.sdi: 存储表结构信息
  • xxx.MYD: 存储数据
  • xxx.MYI: 存储索引

1.2.3、存储引擎:Memory

Memory引擎的表数据时存储在内存中,若受到硬件问题、或断电问题的影响,表中数据消失,一般用于临时缓存使用

特点:

  • 内存存放,访问速度较快
  • hash索引(默认)

文件:

  • xxx.sdi:存储表结构信息
  • 数据, 都在内存中

1.2.4、InnoDB, MyISAM, Memory的区别,使用场景

区别:

InnoDB引擎与MyISAM引擎的区别 ?

  • InnoDB 支持事务,而MyISAM不支持
  • InnoDB 支持行锁和表锁,而MyISAM仅支持表锁, 不支持行锁
  • InnoDB 支持外键, 而MyISAM不支持

适合的使用场景:

  • InnoDB:对事务的完整性有高要求,且在并发条件下要求数据的一致性,数据操作包含很多更删操作

  • MyISAM : 以读操作和插入操作为主,有少量更新、删除操作,且对事务完整性、并发性要求不高

  • MEMORY:数据保存在内存中,访问速度快,用于临时表及缓存。缺陷就是 对表的大小有限制,太大的表无法缓存在内存中,且断电后数据消失 无法保障数据的安全性。

MyISAM和MEMORY被MongoDB和Redies等 NoSQL 的DBMS所取代

二、索引

索引(index)是MySQL中高效获取数据数据结构(有序)

索引优缺点:

优点:

  • 提高数据检索效率,降低数据库的I/O成本
  • 通过索引对数据进行排序,降低数据排序的成本,降低CPU消耗

缺点:

  • 索引占用了数据库的空间 (磁盘便宜
  • 索引提高了查询的效率,降低了更新表(Insert,update,delete)的速度,因为增删改表也需要同时维护索引。 (查询的次数远大于增删改操作的次数

2.1、索引结构:B+Tree, Hash, R-tree

MySQL的索引是在存储引擎层中实现的,不同的存储引擎有不同的索引结构:

  • B+Tree索引:最常见的索引类型,大部分引擎都支持 B+ 树索引
  • Hash索引 :底层数据结构是用哈希表实现的, 只有精确匹配索引列的查询才有效,不支持范围查询
  • R-tree(空间索引:是MyISAM引擎的一个特殊索引类型,主要用于地理空间数据类型,通常使用较少
  • Full-text(全文 索引):是一种通过建立倒排索引,快速匹配文档的方式。

二叉树

如果顺序插入:

  • 顺序插入时,会形成一个单项链表,查询性能大大降低
  • 大数据量情况下,层级较深,检索速度慢

红黑树

  • 解决二叉树的顺序插入后,树不平衡的问题
  • 在大数据量的情况下,层级较深,检索速度较慢

B-Tree 多路平衡查找树:

以一颗最大度数为5的b-tree为例:

  • 五个指针: 指针1(key<20),指针2(20<key<30),指针3(30<key<62),指针4(62<key<89),指针5(key>89)

  • 四个key:20,30,62,89


树的度数指一个结点的子节点个数

中间元素向上分裂

  • 一个结点可以包含2个以上的子节点,解决了红黑树 层级较深的问题

  • B树中,非叶子节点和叶子结点都会存放数据,一页中可以放的指针和数据太少,IO次数变多

B+树
以一个最大度数为4的b+树为例:

度数为4,key有三个,指针有四个

  • 索引部分:仅仅起到索引数据的作用,不存储数据
  • 数据存储部分,在其叶子节点中要存储具体的数据

与 B-Tree相比,区别:

  • 所有的数据都会出现在叶子节点。
  • 叶子节点形成一个单向链表。
  • 非叶子节点仅仅起到索引数据作用,具体的数据都是在叶子节点存放的。

MySQL优化后的B+ Tree:

  • 在原B+Tree的基础上,变成了双向循环链表,形成了带有顺序指针的B+Tree

为什么 InnoDB 存储引擎选择使用 B+tree 索引结构?

  • 相对于二叉树,层级更少,搜索效率高;
  • 对于B-tree,无论是叶子节点还是非叶子节点,都会保存数据,这样导致一页中存储 的键值减少,指针跟着减少,要同样保存大量数据,只能增加>树的高度,导致性能降低;
  • 相对Hash索引,B+tree支持范围匹配及排序操作;

2.2、索引分类:主键/唯一/常规/全文索引,聚集/二级索引


  • 如果存在主键,主键索引就是聚集索引

  • 如果不存在主键,将使用第一个唯一(UNIQUE)索引作为聚集索引。 (在字段上加了唯一约束的时候,会自动加上该字段的唯一索引

  • 如果表没有主键,或没有合适的唯一索引,则InnoDB会自动生成一个rowid作为隐藏的聚集索引

以下哪个SQL语句的执行效率会更高,为什么?(id为主键,name字段创建的有索引

​ ① select * from user where id = 10;

​ ② select * from user where name = 'Arm';

答:语句①只需要一次索引扫描,语句②需要先查找主键 再回表使用聚集索引获取一整行数据;因此语句①的执行效率会更高
InnoDB主键索引的B+Tree高度为多高?

答:假设一行数据大小1k,一页大小为16K 可以存储16行这样的数据,InnoDB指针占用6个字节空间空间,假设key占用8个字节,

树高度为2:

非叶子结点页存储key的数量:n * 8 + (n + 1) * 6 = 16 * 1024, n = 1170,key 1170个,指针1171个

一个指针指向一个叶子结点的页,一页能存储16行,所以可以存放1171 * 16 = 18736

树高度为3:

1171 * 1171 * 16 = 273,993,856 可以存放百万级别的数据

2.3、索引语法:索引的创建,查看,删除

  • 创建索引
sql 复制代码
CREATE [UNIQUE | FULLTEXT] INDEX index_name ON table_name (index_col_name, ...) ;
#index_name 索引名;index_col_name, ...多个字段 

如果一个索引只关联一个字段,则该索引称为单列索引

如果一个索引关联多个字段,则该索引称为 联合索引/组合索引

  • 查看该表的所有索引 SHOW INDEX FROM table_name ;

  • 删除该表的indext_name的索引 DROP INDEX index_name ON table_name ;

举例




2.4、SQL性能分析:执行频率,慢查询日志,profile,explain

  • SQL 执行频率:使用命令查看全局/当前会话的增删改查次数 (7个下划线)

    • show [session|global] status like 'Com_______'; 可以提供服务器增删改查的访问频次
      主要对于查询较多的数据库的数据库进行优化,若以增删改为主 考虑不对其进行索引优化
      session 当前会话的,golbal 全局的
  • 使用慢查询日志定位查询效率较低的SQL语句,从而对单个SQL语句进行优化

    • 慢查询日志:记录了所有执行时间超过指定参数(long_query_time,单位:秒,默认10秒)的所有 SQL语句的日志

      • 查看MySQL的慢查询日志是否开启,默认关闭:show variables like 'slow_query_log';
    • 尝试使用慢查询日志:

      • 一个进程执行 sudo tail -f /var/log/mysql/mysql-slow.log查看日志文件的尾行
      • 一个进程进入MySQL执行 SELECT BENCHMARK(1000000000, 1+1);进行长时间的压测
  • profile查看指令耗时 。执行指令时,当查询时间超过设置时间后才会写慢查询入日志,但有些SQL语句任务简单 时间在超过的设置时间左右 是不合理的,如何发现这类SQL语句 可以使用 profile 在做SQL优化时帮助我们了解时间耗费情况

    • 查看当前数据库是否支持profile select @@have_profiling ;

    • 查看当前数据库是否打开了 profiling select @@profiling;

    • 开启profiling SET profiling = 1;

    • 使用指令查看当前会话指令的执行耗时

      • show profiles; 查看每一条SQL的耗时基本情况
      • show profile for query query_id; 查看指定query_id的SQL语句各个阶段的耗时情况
      • show profile cpu for query query_id; 查看指定query_id的SQL语句CPU的使用情况
  • explain执行计划:其它的都是关于时间上的优化,explain是关于执行顺序的优化。

    EXPLAIN 或 DESC命令获取 MySQL 如何执行 SELECT 语句的信息,包括在 SELECT 语句执行过程中表如何连接和连接的顺序。
    explain / desc EXPLAIN SELECT 字段列表 FROM 表名 WHERE 条件 ;

    直接在select语句之前加上关键字

    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

      NULL性能最好,all性能最差。

    • possible_key:显示可能应用在这张表上的索引,一个或多个

    • key:实际使用的索引,如果为NULL,则没有使用索引。

    • key_len:表示索引字段最大可能长度,并非实际长度,不损失精确性的前提下越短越好

    • rows:MySQL认为必须要执行查询的行数,innodb引擎的表中是一个估计值, 并不总是准确

    • filtered:表示返回结果的行数占需读取行数的百分比,值越大越好

    • extra:额外字段

2.5、索引使用:单列索引,联合索引,前缀索引

  • 联合索引:即一个索引包含了多个列

    • 最左前缀法则:联合索引的使用要遵循最左法则,最左前缀法则指的是查询从索引的最左列开始, 并且不跳过索引中的列。如果跳跃某一列,索引将会部分失效(后面的字段索引失效)
      profession、age、status三个字段都使用到了索引,与查询时的位置顺序无关

      sql 复制代码
      # 1. 为表中的字段:profession、age、status创建联合索引
      create index  pro_age_sta_idx on tb_user(profession,age,status);
      # ----------- 测试 联合索引是否失效,数字是explain的索引长度----------------
      # profession、age、status三个字段都使用到了索引  57
      explain select * from tb_user where profession = '软件工程' and age = 31 and status = '0'; 
      # profession、age 字段使用到了索引  49
      explain select * from tb_user where profession = '软件工程' and age = 31;
      # profession 字段使用到了索引 47
      explain select * from tb_user where profession = '软件工程';
      # 全表扫描,没有使用索引,不符合最左前缀法则 NULL
      explain select * from tb_user where age = 31 and status = '0';
      explain select * from tb_user where status = '0';
      # profession 字段使用到了索引,跳过了age,因此age后的status字段无法使用索引 47
      explain select * from tb_user where profession = '软件工程' and status = '0';
      # profession、age、status三个字段都使用到了索引,与查询时的位置顺序无关 57
      explain select * from tb_user where age = 31 and status = '0' and profession = '软件工程';
  • 单列索引:即一个索引只包含单个列

在业务场景中,如果存在多个查询条件,考虑针对于查询字段建立索引时建议建立联合索引, 而非单列索引。

  • 前缀索引
    字段类型为字符串(varchar,text),若需要索引是很长的字符串,会使索引长度过长,浪费大量磁盘IO 影响查询效率。因此仅对字符串的一部分前缀建立索引,节约索引空间,提高查询效率

    • 创建前缀索引:create index idx_xxxx on table_name(column(n)) ;

    • 前缀长度 n:根据索引选择性决定,选择性指不重复的索引值(基数)和 表记录总数的比值,索引选择性越高则查询效率越高。例如:唯一索引的选择性是1,是最好的索引选择性,性能最好

      sql 复制代码
      # 查询使用email整个字符串的索引选择比   1.0000
      select count(distinct email) / count(*) from tb_user;
      # 查询使用email 使用前缀5个字符串的索引选择比  0.9583
      select count(distinct substring(email,1,5)) / count(*) from tb_user ;
      # 查询使用email 使用前缀2个字符串的索引选择比   0.9167
      select count(distinct substring(email,1,2)) / count(*) from tb_user ;
      # 对字段email建立前缀索引,前缀长度为5  
      create index email_idx on tb_user(email(5));
      # 查看使用email前缀索引进行查询的执行结构
      explain select * from tb_user where email = 'xiaoyu666@qq.com'; 

    修改n,查看索引选择性的值,在索引选择性和前缀长度 做权衡

    • 前缀索引的查询流程:

      • 查询字符串的前N个字符串去索引表中查找 获取到对应前缀的主键ID,找到后回表去主键表中获取到整行数据(整个字符串),对比是否与查找字符串相等
      • 若在二级索引的表中 下一条数据的前缀N和当前查找的前缀N不等,则直接返回;
      • 若相等,则获取下一条数据的主键ID,回表去主键表中获取整行数据,查看字符串是否和查询字符串相等;

2.6、索引使用:验证索引效率,索引失效,SQL提示,覆盖索引

  • 验证索引效率

    • 在未建立索引时,执行SQL语句 查看SQL耗时:

      select * from tb_sku where sn = '100000003145001';

    • 对字段sn建立索引后,重新进行查询,查看SQL耗时

      create index sn_idx on tb_sku(sn);

      select * from tb_sku where sn = '100000003145001';

      show index from tb_sku;

使用explain解释和分析 查询语句

explain select * from tb_sku where sn = '100000003145001';

  • 索引失效情况:

    • 不遵循最左前缀法则(联合索引):没有有从索引的最左列开始,联合索引失效;中间跳过了索引的中间字段,则该字段后的联合索引都失效

    • 范围查询(联合索引):联合索引中,出现范围查询(>,<),范围查询右侧的列索引失效

      sql 复制代码
      # profession、age使用到了索引, 49
      explain select * from tb_user where profession = '软件工程' and age > 30 and status = '0';
      # profession、age、status三个字段都使用到了索引  57
      explain select * from tb_user where profession = '软件工程' and age >= 30 and status = '0';
    • 索引列运算:在索引列上进行运算操作, 索引将失效

    • 字符串不加引号:字符串类型字段使用时,不加引号,索引将失效

    • 模糊查询:尾部模糊匹配,索引不会失效;头部模糊匹配,索引失效。

    • or连接条件:or左右两侧的字段必须都有索引,若左有 右无 则左的索引失效

    • 数据分布影响:如果MySQL评估使用索引比全表更慢,则不使用索引

  • SQL提示:是优化数据库的一个重要手段,简单说,是在SQL语句中加入一些人为提示达成优化操作

    sql 复制代码
    # SQL提示 使用者根据自己的倾向 建议/忽略/强制使用 MySQL使用哪个索引进行查询
    # profession字段有两个索引:单列索引 profession_idx,联合索引 pro_age_sta_idx
    
    #use index: 建议MySQL使用哪一个索引完成此次查询(仅仅是建议,mysql内部还会再次进行评估)
    explain select * from tb_user use index(profession_idx) where profession = '软件工程';
    #ignore index: 忽略指定的索引
    explain select * from tb_user ignore index(pro_age_sta_idx) where profession = '软件工程';
    #force index: 强制使用索引
    explain select * from tb_user force index(profession_idx) where profession = '软件工程';
  • 覆盖索引:指查询使用了索引,并且需要返回的列,在该索引中已经全部能够找到。尽量使用覆盖索引,减少select *。 尽量返回使用索引就能得到的列,而不是需要回表

2.7、索引设计原则

  • 针对于数据量较大,且查询比较频繁的表建立索引
  • 针对于常作为查询条件(where)、排序(order by)、分组(group by)操作的字段建立索引
  • 尽量选择区分度高的列作为索引,尽量建立唯一索引,区分度越高,使用索引的效率越高
  • 如果是字符串类型的字段,字段的长度较长,可以针对于字段的特点,建立前缀索引
  • 尽量使用联合索引,减少单列索引,查询时,联合索引很多时候可以覆盖索引,节省存储空间, 避免回表,提高查询效率。
  • 要控制索引的数量,索引并不是多多益善,索引越多,维护索引结构的代价也就越大,会影响增删改的效率
  • 如果索引列不能存储NULL值,请在创建表时使用NOT NULL约束它。当优化器知道每列是否包含 NULL值时,它可以更好地确定哪个索引最有效地用于查询。
相关推荐
云和数据.ChenGuang28 分钟前
Django 应用安装脚本 – 如何将应用添加到 INSTALLED_APPS 设置中 原创
数据库·django·sqlite
woshilys1 小时前
sql server 查询对象的修改时间
运维·数据库·sqlserver
Hacker_LaoYi1 小时前
SQL注入的那些面试题总结
数据库·sql
建投数据2 小时前
建投数据与腾讯云数据库TDSQL完成产品兼容性互认证
数据库·腾讯云
Hacker_LaoYi3 小时前
【渗透技术总结】SQL手工注入总结
数据库·sql
岁月变迁呀3 小时前
Redis梳理
数据库·redis·缓存
独行soc3 小时前
#渗透测试#漏洞挖掘#红蓝攻防#护网#sql注入介绍06-基于子查询的SQL注入(Subquery-Based SQL Injection)
数据库·sql·安全·web安全·漏洞挖掘·hw
你的微笑,乱了夏天4 小时前
linux centos 7 安装 mongodb7
数据库·mongodb
工业甲酰苯胺4 小时前
分布式系统架构:服务容错
数据库·架构
独行soc5 小时前
#渗透测试#漏洞挖掘#红蓝攻防#护网#sql注入介绍08-基于时间延迟的SQL注入(Time-Based SQL Injection)
数据库·sql·安全·渗透测试·漏洞挖掘