mysql作为常用的关系型数据库，更新语句和查询语句是日常开发中使用频率最高的两类sql语句，二者在整体架构上的执行路径有相似之处，但具体流程存在不少差异。
mysql基础架构回顾
mysql整体分为server层和存储引擎层两部分。server层包含连接器、查询缓存、分析器、优化器、执行器等核心组件，所有跨存储引擎的功能都在这一层实现。存储引擎层负责数据的存储和读取，常见的存储引擎有InnoDB、MyISAM等，默认使用InnoDB。
查询语句的执行流程
以一条简单的查询语句为例：SELECT * FROM user WHERE id = 1;，其执行流程如下：
1. 连接器
客户端先通过连接器与mysql建立连接，连接器会校验用户名、密码等信息，验证通过后维持连接，同时获取用户的权限信息。
2. 查询缓存
如果查询缓存功能开启，mysql会先检查这条查询语句是否在缓存中，如果命中缓存则直接返回结果，跳过后续步骤。不过查询缓存在mysql 8.0版本已经被移除，实际使用中需要注意版本差异。
3. 分析器
如果没有命中缓存，分析器会对sql语句进行词法分析和语法分析，识别出这是一条查询语句，提取出表名、查询条件等信息，同时校验sql语法是否正确。
4. 优化器
优化器会根据表的索引情况、数据分布等信息，决定使用哪个索引，或者调整表的连接顺序，生成最优的执行计划。
5. 执行器
执行器会根据优化器生成的执行计划，调用存储引擎的接口读取数据，然后返回给客户端。如果表没有索引，执行器会全表扫描找到符合条件的记录。
更新语句的执行流程
以一条更新语句为例：UPDATE user SET age = 20 WHERE id = 1;，其执行流程如下：
1. 连接器、分析器、优化器
这三个步骤和查询语句的流程完全一致，连接器建立连接校验权限，分析器解析sql识别为更新语句，优化器生成执行计划。
2. 执行器调用存储引擎接口
执行器先调用存储引擎的查询接口，找到id=1这条记录。如果这条记录已经在内存中，直接返回；如果不在内存中，先从磁盘读入内存再返回。
3. 记录redo log
存储引擎拿到记录后，会把更新操作记录到redo log中，此时redo log处于prepare状态，然后告知执行器执行完成，随时可以提交事务。
4. 记录binlog
执行器收到存储引擎的通知后，会生成这条更新操作的binlog，并把binlog写入磁盘。
5. 提交事务
执行器调用存储引擎的提交事务接口，存储引擎把之前写入的redo log状态修改为commit状态，更新操作完成。
这里用到的redo log和binlog是mysql中重要的日志组件，redo log是InnoDB引擎特有的物理日志，用于保证事务的持久性；binlog是server层的逻辑日志，用于主从复制和数据恢复。
两种语句的核心差异对比
通过上面的流程拆解，可以总结出两者的核心差异：
- 操作目标不同：查询语句仅读取数据，不会修改数据内容；更新语句需要修改数据，涉及数据的写入操作。
- 日志写入不同：查询语句不需要写入任何日志；更新语句需要先后写入redo log和binlog，保证数据的一致性和可恢复性。
- 缓存处理不同：查询语句会优先检查查询缓存（旧版本）；更新语句执行时，会把对应表的查询缓存全部清空，避免缓存数据不一致。
- 锁机制不同：查询语句一般使用共享锁或者不加锁；更新语句会对操作的记录加排他锁，避免其他事务同时修改同一条数据。
代码示例验证差异
我们可以通过开启日志的方式，观察两种语句执行时的日志差异，以下是简单的验证代码：
-- 开启binlog记录 SET GLOBAL log_bin = ON; -- 开启general_log查看所有执行的sql SET GLOBAL general_log = ON; -- 执行查询语句 SELECT * FROM user WHERE id = 1; -- 执行更新语句 UPDATE user SET age = 20 WHERE id = 1; -- 查看general_log中的记录，会发现更新语句有额外的日志写入操作 -- 查看binlog文件，会发现更新语句生成了对应的binlog记录，查询语句没有
常见问题解答
为什么更新语句需要写两份日志
redo log是InnoDB引擎层的日志，用于保证事务崩溃后数据可以恢复；binlog是server层的日志，用于主从复制和全量恢复。两者分工不同，所以更新语句需要同时写入两份日志，通过两阶段提交保证两份日志的逻辑一致性。
更新语句的执行效率一定比查询语句低吗
不一定。如果查询语句没有走索引，需要全表扫描大量数据，而更新语句走了索引只修改少量记录，更新语句的执行效率可能更高。不过一般情况下，更新语句因为多了日志写入和锁操作，平均执行耗时比同条件的查询语句更高。