MySQL基础三问:底层逻辑、正在执行、日志观察

本文介绍MySQL查询的底层原理,包括连接器、分析器、优化器、执行器等组件的工作流程,以及如何查看正在执行的MySQL语句和观察MySQL运行过程中的日志信息。

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

背景及目录:

经常面试会遇到且实际工作中也会应用到的三个场景:

一.mysql查询时的底层原理是什么?

二.如何查看正在执行的mysql语句?

三.如何观察mysql运行过程中的日志信息?

- - - - - - - - - -分割线- - - - - - - - - - -

一.mysql查询时的底层原理是什么?

mysql底层使用的组件主要分别两个部分:包含Server层与Store层

Server层

主要包括连接器、查询缓存、分析器、优化器、执行器等,涵盖 MySQL 的大多数核心服务功能,以及所有的内置函数(如日期、时间、数学和加密函数等),所有跨存储引擎的功能都在这一层实现,比如存储过程、触发器、视图等。

Store层

存储引擎层负责数据的存储和提取。其架构模式是插件式的,支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB,它从 MySQL 5.5.5 版本开始成为了默认存储引擎。也就是说如果我们在create table时不指定表的存储引擎类型,默认会给你设置存储引擎为InnoDB。

1.连接器:

使用各种客户端连接mysql时会使用到连接器,这些客户端要向mysql发起通信都必须先跟Server端建立通信连接,而建立连接的工作就是有连接器完成的。 连接器负责跟客户端建立连接、获取权限、维持和管理连接。连接命令一般是这么写的:

[root@192 ~]# mysql -h host[数据库地址] -u root[用户] -p root[密码] -P 3306

mysql -u root -p

连接器就要开始认证你的身份,这个时候用的就是你输入的用户名和密码;如果用户名或密码不对,你就会收到一个"Access denied for user"的错误,然后客户端程序结束执行

连接器会到权限表里面查出你拥有的权限。之后,这个连接里面的权限判断逻辑,都将依赖于此时读到的权限,连接成功如下

​show grants for root@"%"; 查看当前用户的权限

MySQL 拿到一个查询请求后,会先到查询缓存看看,之前是不是执行过这条语句。之前执行过的语句及其结果可能会以 key-value 对的形式,被直接缓存在内存中。key 是查询的语句,value 是查询的结果。如果你的查询能够直接在这个缓存中找到 key,那么这个 value 就会被直接返回给客户端。

查看当前mysql实例是否开启缓存机制:

mysql> show global variables like "%query_cache_type%";

监控查询缓存信息:

mysql> show status like'%Qcache%'; //查看运行的缓存信息

如果语句不在查询缓存中,就会继续后面的执行阶段。执行完成后,执行结果会被存入查询缓存中。你可以看到,如果查询命中缓存,MySQL 不需要执行后面的复杂操作,就可以直接返回结果,这个效率会很高建议大家在静态表里使用查询缓存,什么叫静态表呢?就是一般我们极少更新的表。比如,一个系统配置表、字典表,那这张表上的查询才适合使用查询缓存。好在 MySQL 也提供了这种“按需使用”的方式。你可以将my.cnf参数 query_cache_type 设置成 DEMAND。

my.cnf #query_cache_type有3个值 0代表关闭查询缓存OFF,1代表开启ON,2(DEMAND)代表当sql语句中有SQL_CACHE关键词时才缓存 query_cache_type=2

2.分析器

如果没有命中查询缓存,就要开始真正执行语句了。首先,MySQL 需要知道你要做什么,因此需要对 SQL 语句做解析。

分析器先会做“词法分析”。你输入的是由多个字符串和空格组成的一条 SQL 语句,MySQL 需要识别出里面的字符串分别是什么,代表什么。

MySQL 从你输入的"select"这个关键字识别出来,这是一个查询语句。它也要把字符串“T”识别成“表名 T”,把字符串“ID”识别成“列 ID”。

做完了这些识别以后,就要做“语法分析”。根据词法分析的结果,语法分析器会根据语法规则,判断你输入的这个 SQL 语句是否满足 MySQL 语法。

如果你的语句不对,就会收到“You have an error in your SQL syntax”的错误提醒,比如下面这个语句 from 写成了 "rom"。

分析器分成6个步骤:

(1)词法分析 (2)语法分析 (3)语义分析 (4)生成执行树 (5)生成执行计划(6)计划执行

3.优化器

优化器决定了要使用的索引,各个表的连接顺序

优化器是在表里面有多个索引的时候,决定使用哪个索引;或者在一个语句有多表关联(join)的时候,决定各个表的连接顺序。比如你执行下面这样的语句,这个语句是执行两个表的 join:

既可以先从表 test1 里面取出 name=yangguo的记录的 ID 值,再根据 ID 值关联到表 test2,再判断 test2 里面 name的值是否等于 yangguo。

也可以先从表 test2 里面取出 name=xiaolongnv 的记录的 ID 值,再根据 ID 值关联到 test1,再判断 test1 里面 name 的值是否等于 yangguo。

这两种执行方法的逻辑结果是一样的,但是执行的效率会有不同,而优化器的作用就是决定选择使用哪一个方案。优化器阶段完成后,这个语句的执行方案就确定下来了,然后进入执行器阶段

4.执行器

开始执行的时候,要先判断一下你对这个表 T 有没有执行查询的权限,如果没有,就会返回没有权限的错误,如下所示 (在工程实现上,如果命中查询缓存,会在查询缓存返回结果的时候,做权限验证。查询也会在优化器之前调用 precheck 验证权限)。

如果有权限,就打开表继续执行。打开表的时候,执行器就会根据表的引擎定义,去使用这个引擎提供的接口。

比如我们这个例子中的表 test 中,ID 字段没有索引,那么执行器的执行流程是这样的:

(1)调用 InnoDB 引擎接口取这个表的第一行,判断 ID 值是不是 10,如果不是则跳过,如果是则将这行存在结果集中;

(2)调用引擎接口取“下一行”,重复相同的判断逻辑,直到取到这个表的最后一行。

(3)执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。

至此,这个语句就执行完成了。对于有索引的表,执行的逻辑也差不多。第一次调用的是“取满足条件的第一行”这个接口,之后循环取“满足条件的下一行”这个接口,这些接口都是引擎中已经定义好的。你会在数据库的慢查询日志中看到一个 rows_examined 的字段,表示这个语句执行过程中扫描了多少行。这个值就是在执行器每次调用引擎获取数据行的时候累加的。在有些场景下,执行器调用一次,在引擎内部则扫描了多行,因此引擎扫描行数跟 rows_examined 并不是完全相同的。

5.bin-log归档

删库是不需要跑路的,因为我们的SQL执行时,会将sql语句的执行逻辑记录在我们的bin-log当中,什么是bin-log呢?

binlog是Server层实现的二进制日志,他会记录我们的cud操作。Binlog有以下几个特点:

(1)Binlog在MySQL的Server层实现(引擎共用)

(2)Binlog为逻辑日志,记录的是一条语句的原始逻辑

(3)Binlog不限大小,追加写入,不会覆盖以前的日志

如果,我们误删了数据库,可以使用binlog进行归档!要使用binlog归档,首先我们得记录binlog,因此需要先开启MySQL的binlog功能。

配置my.cnf

配置开启binlog log-bin=/usr/local/mysql/data/binlog/mysql-bin 注意5.7以及更高版本需要配置本项:server-id=123454(自定义,保证唯一性); #binlog格式,有3种statement,row,mixed binlog-format=ROW #表示每1次执行写入就与硬盘同步,会影响性能,为0时表示,事务提交时mysql不做刷盘操作,由系统决定 sync-binlog=1 复制代码

binlog命令:

mysql> show variables like '%log_bin%'; 查看bin-log是否开启 mysql> flush logs; 会多一个最新的bin-log日志 mysql> show master status; 查看最后一个bin-log日志的相关信息 mysql> reset master; 清空所有的bin-log日志

二.如何查看正在执行的mysql语句?

首先:processlist表位于information_schema库中,主要是存储的MySQL线程的一些基本信息。我们使用

desc information_schema.processlist来查看表结构:

ID: 线程的id USER: 线程属于哪一个用户 HOST:客户端的host信息:hostname+端口 DB:线程在哪一个数据库下 COMMAND:线程使用哪一种命令在执行,空闲的线程状态为sleep TIME:线程已经运行的时间,秒为单位 STATE:线程正在做什么:当前的状态,行为,或者事件 INFO:线程正在执行的语句,但是这个并不是很准确,所以需要使用其他的方式来完成我们的目标。 使用show processlist 或者 select * from information_schema.processlist查看processlist表

并且可以直接kill掉卡死的进程信息

show processlist select * from information_schema.processlist

1.拿到正在执行的processlist_id

select id from information_schema.processlist

2.拿到与processlist_id对应的thread_id

select thread_id from performance_schema.threads where processlist_id in (上一步拿到的processlist_id列表)

3.拿到正在执行的sql语句

select thread_id, sql_text from performance_schema.events_statements_current where thread_id in (上一步拿到的thread_id列表)

4.完整的sql语句如下:

SELECT a.*, c.thread_id, c.sql_text from information_schema.processlist a LEFT JOIN performance_schema.threads b on a.id = b.PROCESSLIST_ID LEFT JOIN performance_schema.events_statements_current c on c.THREAD_ID = b.THREAD_ID;

​三.如何观察mysql运行过程中的日志信息?

查看主要之前说bin-log日志信息。

1.查看是否启用了日志:

show variables like 'log_bin';

2.查看当前的日志

show master status;

 3.查看日志文件内容:

mysqlbinlog binlog.0000294.mysql有以下几种日志:

错误日志: -log-err

查询日志: -log

慢查询日志: -log-slow-queries

更新日志: -log-update

二进制日志: -log-bin

<think>嗯,用户的是MySQL的复制数据流程。首先,我得回忆一下MySQL复制的基本概念。复制主要是用来做数据冗余、负载均衡或者高可用性的,对吧?主从架构,主库(master)把数据变更同步到从库(slave)。那具体流程是怎样的呢?可能涉及到二进制日志,主库写日志,从库读日志然后应用这些变更。 首先,主库那边,当有数据变更操作的时候,比如INSERT、UPDATE这些,应该会记录到二进制日志(binlog)里。对,这个binlog是用来记录所有修改了数据库数据的操作。然后从库需要连接到主库,获取这些binlog,再在本地重放,这样数据就同步了。 接下来,从库这边应该有个线程参与复制过程。一个是I/O线程,负责连接主库,请求binlog,然后把接收到的事件写入到自己的中继日志(relay log)里。另一个是SQL线程,读取relay log中的事件,解析执行,更新从库的数据。可能还有第个线程,比如在MySQL 5.6之后的多线程复制,会有多个worker线程来并行应用事务,加快同步速度。 不过,用户可能想知道更详细的步骤。比如复制的具体步骤:主库开启binlog,从库配置连接到主库的信息,比如主库的IP、端口、用户和密码,然后启动复制。这时候从库的I/O线程开始拉取binlog,保存为relay log,接着SQL线程应用这些日志。 需要提到复制的种模式:基于语句的复制(SBR)、基于行的复制(RBR)和混合模式(Mixed)。每种模式的优缺点,比如SBR可能在某些情况下出现数据不一致,而RBR记录每一行的变化,更安全但日志量更大。 还有复制的延迟题,可能的原因,比如网络延迟、从库性能不足,或者大事务导致SQL线程应用变慢。用户可能关心如何监控复制状态,比如使用SHOW SLAVE STATUS命令查看Slave_IO_Running和Slave_SQL_Running的状态,以及Seconds_Behind_Master的值。 另外,GTID(全局事务标识符)在复制中的作用,可以简化主从切换和故障恢复,确保每个事务在集群中具有唯一标识。可能还要提到半同步复制,增强数据一致性,主库在提交事务前需要至少一个从库确认接收到日志。 需要确保步骤讲解清晰,逻辑正确。可能用户是刚接触MySQL复制的开发者或者DBA,需要了解基本原理和配置流程。回答时应该分点说明,流程步骤,各组件的作用,以及相关概念,比如binlog、relay log、个线程、复制模式等。 有没有可能用户的是更底层的流程?比如二进制日志的格式,事件传输的具体方式,或者异步、同步复制的区别。或者复制过程中出现错误如何处理,比如主键冲突,网络中断后的恢复方法。不过根据题,用户可能只需要基础流程的介绍,所以保持简明扼要,覆盖主要步骤和关键点即可。 最后检查是否有错误,比如主库的I/O线程?不,主库生成binlog,从库的I/O线程拉取。主库本身可能有dump线程来处理从库的请求,发送binlog事件。这点需要正确描述。主库的binlog dump线程和从库的I/O线程之间的交互。是的,主库在接收到从库的连接请求后,会创建一个binlog dump线程来发送binlog事件。 总结步骤应该是: 1. 主库将数据变更写入binlog。 2. 从库的I/O线程连接主库,请求binlog。 3. 主库的binlog dump线程发送binlog事件给从库。 4. 从库的I/O线程将事件写入relay log。 5. 从库的SQL线程读取relay log并应用变更。 这样流程就清晰了。再加上复制模式、线程作用、可能涉及的监控命令,以及GTID或半同步复制的可选部分,应该就能全面回答用户的题了。避免使用过于专业的术语,但必要的术语需要解释清楚,比如binlog、relay log这些。</think>MySQL 复制是一种常见的主从数据同步机制,其核心流程可概括为以下步骤: --- ### **一、核心流程** 1. **主库记录变更(Master)** - 主库将数据变更(如 `INSERT/UPDATE/DELETE`)以事件形式写入 **二进制日志(binlog)**。 - binlog 是复制的核心,支持种格式:基于语句(SBR)、基于行(RBR)、混合模式(Mixed)。 2. **从库拉取日志(Slave → Master)** - 从库的 **I/O 线程** 连接主库,请求 binlog。 - 主库创建 **Binlog Dump 线程**,将 binlog 事件推送给从库。 3. **从库写入中继日志(Relay Log)** - 从库的 I/O 线程接收 binlog 事件,并写入本地的 **中继日志(relay log)**。 4. **从库应用变更(Slave)** - 从库的 **SQL 线程** 读取 relay log 中的事件,解析并执行,最终同步数据。 --- ### **二、关键组件** | 组件 | 作用 | |----------------|----------------------------------------------------------------------| | **Binlog** | 主库的二进制日志,记录所有数据变更操作。 | | **Relay Log** | 从库的中继日志,临时存储主库推送的 binlog 事件。 | | **I/O 线程** | 从库线程,负责连接主库并拉取 binlog。 | | **SQL 线程** | 从库线程,负责执行 relay log 中的事件,更新从库数据。 | | **Binlog Dump**| 主库线程,响应从库请求,推送 binlog 事件。 | --- ### **、复制模式** 1. **异步复制(默认)** - 主库提交事务后**无需等待从库确认**,性能高,但可能丢数据。 2. **半同步复制** - 主库提交事务后需**至少一个从库确认**收到 binlog,平衡性能与一致性。 3. **组复制(Group Replication)** - 基于 Paxos 协议的多主同步,保障强一致性,用于高可用集群。 --- ### **四、监控与维护** - **查看复制状态** ```sql SHOW SLAVE STATUS\G ``` 关键字段: - `Slave_IO_Running`:I/O 线程是否运行。 - `Slave_SQL_Running`:SQL 线程是否运行。 - `Seconds_Behind_Master`:从库延迟时间(秒)。 - **常见题** - **数据延迟**:网络瓶颈、从库性能不足、大事务阻塞。 - **主从不一致**:手动修改从库数据、复制过滤规则错误。 --- ### **五、扩展:GTID 复制** - **全局事务标识符(GTID)** 为每个事务分配唯一ID,格式为 `server_uuid:事务序号`,简化故障恢复和主从切换。 - **启用 GTID** 在配置文件中设置: ```ini gtid_mode = ON enforce_gtid_consistency = ON ``` --- ### **总结** MySQL 复制通过 binlog 实现主从数据同步,流程包括日志记录、传输、重放个阶段。可根据业务需求选择异步、半同步或组复制模式,并结合 GTID 提升运维效率。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值