Mysql 知识杂记

Tattoo_Welkin

已于 2025-03-17 15:21:38 修改

阅读量947

点赞数

CC 4.0 BY-SA版权

分类专栏： MYSQL 文章标签： mysql

于 2022-04-08 16:51:10 首次发布

本文链接：https://blog.youkuaiyun.com/liushengxi_root/article/details/124043246

MYSQL 专栏收录该内容

7 篇文章

订阅专栏

本文介绍了MySQL事务在不同隔离级别下的行为，特别是在查询与插入操作并行时的影响。重点讲解了最左匹配原则在联合索引中的应用，以及如何理解EXPLAIN语句中的关键字段如rows、type和key。同时，讨论了B+树作为数据库索引的优势，并对比了binlog、dolog和redolog的区别。最后，提到了MySQL 5.6中的索引下推优化技术。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一个事务查询范围,另一个事务插入数据,会发生什么

mysql 事务不加锁一致性读：当事务隔离级别为可重复读时，事务A进行查询，事务B进行改、删除、插入时，进行查询的事务A不受事务B的影响，仍然为原始数据库中的数据，即使事务A内对数据做了更改会提交，事务A查询到的仍然为事务开始之前数据库中的数据；当事务隔离级别为读提交时，事务A会读取事务A内的最新提交的数据，如果事务B对事务有更改或提交新数据，不会影响事务A的查询数据。

最左匹配原则

MySQL建立联合索引时会遵守最左前缀匹配原则，即最左优先，在检索数据时从联合索引的最左边开始匹配。
在这里插入图片描述
可以看到 a 的值是有顺序的，1，1，2，2，3，3，而b的值是没有顺序的1，2，1，4，1，2。但是我们又可发现 a 在等值的情况下，b 值又是按顺序排列的，但是这种顺序是相对的。这是因为MySQL创建联合索引的规则是首先会对联合索引的最左边第一个字段排序，在第一个字段的排序基础上，然后在对第二个字段进行排序。所以b=2这种查询条件没有办法利用索引。

优化 SQL 语句的工具

explain 语句的关键点以及 ES 分析语句性能的关键字

MySQL explain 应用详解(吐血整理🤩)

MySQL索引详解

MySQL执行计划分析

在这里插入图片描述

id：每个执行计划都有一个 id，如果是一个联合查询，这里还将有多个 id。
select_type：表示 SELECT 查询类型，常见的有 SIMPLE（普通查询，即没有联合查询、子查询）、PRIMARY（主查询）、UNION（UNION 中后面的查询）、SUBQUERY（子查询）等。
table：当前执行计划查询的表，如果给表起别名了，则显示别名信息。
partitions：访问的分区表信息。

关键的几个字段：

rows：扫描行
type：访问的类型
key：实际使用到的索引，如果为 null ，则没有使用索引

Type：表示从表中查询到行所执行的方式

（从左往右，越靠左边的越优秀）
NULL > system > const > eq_ref > ref > ref_or_null > index_merge > range > index > ALL

分别解读一下：

system：表只有一行记录
const 表示通过索引一次就找到了，const 用于比较 primary key 或 uique 索引，因为只匹配一行数据，所以很快，如主键置于 where 列表中，MySQL 就能将该查询转换为一个常量。
eq_ref：使用唯一索引扫描，常见于多表连接中使用主键和唯一索引作为关联条件。
ref：非唯一索引扫描，还可见于唯一索引最左原则匹配扫描。
range：索引范围扫描，比如，<，>，between 等操作。
index：index只遍历索引树，通常比All快。因为，索引文件通常比数据文件小，也就是虽然all和index都是读全表，但index是从索引中读取的，而all是从硬盘读的。
ALL：如果一个查询的 type 是 All ,并且表的数据量很大，那么请解决它！！！

Key 字段

实际使用的索引，如果为 null,则没有使用索引，否则会显示你使用了哪些索引，查询中若使用了覆盖索引（查询的列刚好是索引），则该索引仅出现在 key 列表。

Extra字段

using index: Extra 字段里面多了“Using index”，表示的就是使用了覆盖索引, 不需要回表
using index condition: 索引下推；先条件过滤索引；
using where: 服务器Server层收到存储引擎返回的数据之后，会再根据 where 条件进行过滤
using filesort: 排序用到了临时文件
using temporary: 用到了临时表，这样的查询效率是比外部排序更低的，常见于 order by 和 group by。

通过 Show Profile 分析 SQL 执行性能（MYSQL 5.0.37 版本之后支持）

上述通过 EXPLAIN 分析执行计划，仅仅是停留在分析 SQL 的外部的执行情况，如果我们想要深入到 MySQL 内核中，从执行线程的状态和时间来分析的话，这个时候我们就可以选择 Profile。

Profile 除了可以分析执行线程的状态和时间，还支持进一步选择 ALL、CPU、MEMORY、BLOCK IO、CONTEXT SWITCHES 等类型来查询 SQL 语句在不同系统资源上所消耗的时间。以下是相关命令的注释：

SHOW PROFILE [type [, type] ... ]
[FOR QUERY n]
[LIMIT row_count [OFFSET offset]]

type参数：
| ALL：显示所有开销信息
| BLOCK IO：阻塞的输入输出次数
| CONTEXT SWITCHES：上下文切换相关开销信息
| CPU：显示CPU的相关开销信息 
| IPC：接收和发送消息的相关开销信息
| MEMORY ：显示内存相关的开销，目前无用
| PAGE FAULTS ：显示页面错误相关开销信息
| SOURCE ：列出相应操作对应的函数名及其在源码中的调用位置(行数) 
| SWAPS：显示swap交换次数的相关开销信息