敖丙系列--《我们一起进大厂》系列-数据库基础

看在前面

• 原文：敖丙，《我们一起进大厂》系列-数据库基础，掘金 https://juejin.im/post/5e3c21105188254901605b0d（现地址 https://juejin.cn/post/6844904079118827527 ）

• 本篇是敖丙数据库系列的开篇，讲 MySQL 的基本架构与一条 SQL 的查询流程。索引、事务这类主题见系列后续。库内见《敖丙系列--我以为自己对索引很了解，直到我遇到了阿里面试官》《数据库两大神器之索引/锁》。

一、MySQL 基本架构：一条 SELECT 的旅程

• 面试建议：能在白纸上画出架构图。按顺序：连接器 → 查询缓存 → 分析器 → 优化器 → 执行器（再往下才是存储引擎层，如 InnoDB）。

二、连接器

• 负责跟客户端建立连接、获取权限、维持和管理连接。

• 连接过程：TCP 握手 → 身份验证（用户名密码）→ 进入空闲状态。

• show processlist 查看连接，Command 列为 Sleep 即空闲连接。

• wait_timeout 控制断开时间，默认 8 小时。超时断开后重连会收到错误。

• 案例（真实故障）：某政府系统每天早上要重启应用。因为 6 点下班到次日 9-10 点上班的间隔超过 8 小时，连接早被数据库断开。解法是调大超时时间。

长连接的问题与两种解法

• 长连接会导致内存飙升：临时内存管理在连接对象中，断开连接才释放。堆积后可能 OOM、MySQL 重启（在 JVM 侧表现为频繁 Full GC）。

• 方案一：定期断开长连接，或大查询后主动断开重连。

• 方案二：MySQL 5.7+ 可在每次大操作后执行 mysql_reset_connection，重新初始化连接资源。不需断开重连，但会把连接状态恢复如初，更优雅。

三、查询缓存

• 原理同 Redis：语句以 key-value 存在内存中，命中直接返回。同一条语句第二次执行明显更快，就是缓存的效果。

• 弊大于利：对表的任何更新都会清空该表全部查询缓存，命中率极低。只适用"只查不更新"的表（如配置表）。

• 相关开关：query_cache_type 设为 DEMAND 默认不用缓存；SQL_CACHE 显式用缓存；测试真实执行时间用 SQL_NO_CACHE，如 select SQL_NO_CACHE * from B。

• MySQL 8.0 已移除查询缓存，8.0+ 无需再关注。

四、分析器（词法 + 语法）

• 词法分析：识别每个字符串是关键字、表名还是列名。

• 语法分析：判断 SQL 对错，错了会提示并指出错误位置（"You have an error in your SQL syntax"就在这一步抛出）。

五、优化器

• 决定使用哪个索引（主键索引、联合索引等多个可选时由它挑）。

• 优化执行顺序：先查哪个表、先关联还是先过滤——同一个 SQL 多种执行方案，优化器选代价最低的。

六、执行器

• 先做权限判断（原文作者存疑：自研查询系统的表权限可能在系统层而非 MySQL 层做）。

• 调用存储引擎接口逐行判断是否满足条件；有索引时执行较快（引擎接口提前定义好）。

• 排查手段：慢日志的 rows_examined 字段看扫描行数，explain 看执行计划。

七、小结（面试怎么答）

• 口述流程：客户端 TCP 连接（连接器鉴权、管连接）→ 查缓存（8.0 已删）→ 分析器做词法/语法解析。之后优化器定索引与执行顺序。最后执行器校验权限并调引擎接口逐行取数。

• 三个加分点：长连接内存上涨的成因与 mysql_reset_connection；查询缓存为什么被 8.0 移除；rows_examined / explain 定位扫描行数。

• 原文思路参考阿里丁奇《MySQL实战45讲》，另推荐《高性能MySQL》。

内容来源：原文 · 2026-10 整理回填。