先记住两层，而不是一串组件名

MySQL 并不是一个直接读取文件的 SQL 黑盒。Server 层负责理解请求、规划执行与协调过程；存储引擎负责数据存取。换一种存储引擎，并不意味着连接、解析和优化这些通用流程也要重写。第一讲最值得留下的是这条职责边界。

一条查询的主路径

以 SELECT name FROM products WHERE id = 42 为例，可以先用下面这条简化路径建立认知。它描述的是模块分工，不是源码函数调用顺序，也不表示每条语句都要重新建立连接。

  • 连接器：建立会话、完成身份认证，并管理连接状态。
  • 分析与预处理：识别 SQL 结构，检查语法和表、列等对象引用。
  • 优化器：在可行方案中选择访问路径，例如使用什么索引、如何安排关联顺序。
  • 执行器：按计划推进查询，通过存储引擎接口访问数据。
  • 存储引擎：完成具体的数据读取，执行过程最终把查询结果交给客户端。

连接复用，解决的是建立连接的成本

建立连接涉及网络交互、认证和会话初始化，所以连接不应在每条 SQL 后都销毁。长连接有利于复用，但长期持有的会话也可能积累资源。对应用而言，连接池除了复用连接，还需要管理连接寿命和失效状态。这是由本讲延伸出的工程检查项，并非已经做过的性能测试。

  • Sleep 表示连接当前空闲，不等于 SQL 正在执行。
  • 空闲超时和查询执行超时是不同问题；不要用同一个参数解释两种现象。
  • 资料提及的 mysql_reset_connection 是客户端 API，不是一条可以直接提交的 SQL。
  • 权限相关行为需要结合权限类型与版本判断，不把本讲的简化描述理解为所有授权变更都只在重连后生效。

查询缓存：需要标注版本的历史组件

资料中的查询缓存保存的是查询语句与结果的对应关系。表被更新后，相关缓存可能失效，因此写入频繁的业务很难持续获益。MySQL 8.0 已移除这项功能，学习现代版本时，不应把它画成查询必经的一站。这里说的是旧版 Query Cache，也不能据此推断数据库完全没有缓存。

优化器决定方案，执行器落实方案

SQL 描述想得到什么结果，执行计划决定怎么得到它。同一个关联查询，先过滤哪张表、使用哪条索引，可能影响中间结果规模。优化器负责选择方案，执行器负责调用引擎完成工作。不能只凭 SQL 写法就断言实际执行顺序，也不能把“有索引”直接等同于“访问成本低”。

把扫描与返回分开看

如果筛选列没有可用索引，执行过程可能需要读取并检查许多行，最后只返回很少的结果。反过来，走索引也不代表只访问最终返回的行。资料提醒：慢查询日志中的 rows_examined 与存储引擎内部实际扫描量不一定完全相同，分析性能时应先明确指标的统计口径。

两个容易误判的地方

  • 列不存在：本讲将其归入分析阶段；更细地说，语法正确之后还需要对象解析和语义检查，不能把它简单称为关键字拼写错误。
  • 权限校验：不能记成“只在执行器检查一次”。资料已说明优化前可能有权限预检查；缺少权限时，也可能先报告权限错误，而不是暴露表结构信息。

复习时，先回答这三个问题

  • 为什么换了存储引擎，SQL 仍然需要解析与优化？因为这部分通用能力由 Server 层承担。
  • 查询只返回一行，为什么仍然可能很慢？返回行数不代表扫描量，还要检查访问路径。
  • 在 MySQL 8.0 中找不到 query_cache_type，该往哪里排查？先确认版本差异，不要直接当作安装问题。

下一步学习

查询路径明确后，再沿着更新语句理解日志与事务。本专栏按实际学习进度追加笔记；尚未整理的课程不会预先发布为空文章。